DevOps，尤其是持续集成（CI）和持续交付（CD），是过去几年在软件开发行业被广泛采用的术语。目前，它的使用已经超出了开发范围，进入了各个部门，希望减少长交付周期和增加产品迭代。对于那些不熟悉软件领域的术语，或者不熟悉想法背后的前提的人：CI/CD本质上是将软件开发项目交付到生产中的自动化，更广泛的目标是使开发和操作更紧密地结合在一起。在本博客中，我们将主要关注CD，因为它与HANA XS开发有关。

在SAP it内部，与许多其他it部门一样，我们正试图增加和简化HANA XS项目的部署，并转向更灵活的方法，为我们的内部客户提供解决方案。

首先，云服务器哪个好，一些背景：正如许多XS开发人员知道，行业云，HANA repo不一定是最容易使用的"文件系统"。数据以适当的格式存储在数据库中，并且每个文件都需要激活，这使得移动或复制之类的基本操作很难自动化。为了解决这个问题，大数据时代，我们决定所有的代码部署都将使用HANA首选的原生"打包"文件类型delivery units（DU）来完成。这些包含项目（或项目子集）的整个活动代码库、更改的以及未更改的文件。

在过去，云 服务器，我们分别手动将代码部署到每个实例，这需要手动干预和开发人员/操作可用性，我们希望可以简化这些。我们决定使用的DU导入过程是SPS09中通过名为HDBALM的命令行工具引入的一个特性。这允许任何安装了HANA客户端的PC将软件包和传送单元导入HANA服务器。虽然有从传统的文件系统文件夹系统提交和激活单个文件的选项（使用文件API），但我们觉得DU的好处更适合我们的用例（例如，可能需要按特定顺序创建的hdb*对象）。

因为我们能够使用我们需要一些东西来完成任务！我们使用了我们的内部实例大西洋竹子。我们将此服务器用于HCP HTML5和Java应用程序，这使得将项目分组在一起成为一个合乎逻辑的选择。我们的构建代理是redhat发行版，并安装了HANA客户端。我们还通过SSL证书进行复制，因为我们的hana服务器使用https，而hdbalm需要https。

在本例中，我们的环境相对简单，有一个开发、测试和生产专用的hana HCP实例。

我们将"准备部署"交付单元存储在我们的内部Github实例上，我们这样做是为了文件是版本控制的，而且对我们的开发团队也是可见和可访问的。前提是开发团队将在sprint之后推送交付单元的一个版本，并准备部署以进行测试。这也很容易成为一个文件系统。然而，我们喜欢使用Github repo的push/tag/release来触发构建部署。

仅供参考：Bamboo是一个很好的工具，几乎是零成本壁垒（10美元）。如果您正在考虑一个安装快速、简单（*nix）和设置的构建服务器，我强烈建议您使用它。

由于我们已经讨论了一些逻辑细节，下面是一些技术细节，涵盖了这个主题：

如前所述，我们的构建过程是由一个新的交付单元触发的，该单元将被提交到我们的github回购。我们的bamboo构建代理将获取构建，将其保存在构建服务器上，并将其部署到我们的测试实例中。一封电子邮件被发送到我们的开发和测试团队的结果。在导入过程之前，我们检查服务器上现有交付单元的版本标识符，随后，店铺淘客，我们在导入后再次检查它以进行比较，并确定导入是否成功（以及导入语句的结果）

（请记住下面的命令包括$bamboo\u变量），但用实际值替换它们就可以了。

您可以在github gist中找到代码（它将在此处显示）维护）

一旦我们的版本在我们的测试环境中进行了测试并准备好进行生产部署，我们就使用Bamboo的部署功能将交付单元部署到我们的生产实例中。这个过程与test相同，只是交付单元不是从github提取的，而是构建作业工件（因为我们要发布的代码可能不是当前dev repo du中的代码）。在这种情况下，我们总是指定开发人员的版本来测试构建作业。

我们的生产部署（目前）不是由开发人员完成，

而是由我们的操作团队完成的。这仍然是竹制的。

竹制屏幕截图（仅供参考）

HANA XSA项目上的Devops

由于我们不再有XSA上的HANA存储库，我们的构建作业/过程将大大简化，与新平台上的传统项目非常相似。（太棒了！）

如果您有任何意见、问题或建议，我们很乐意听到并分享更多关于这些主题的信息。

嗨，保罗，

在发现SAP HANA部署Shell并发表评论后，我进一步搜索并找到了您的博客。也许你可以在我现有的帖子上发表评论，因为我的用例DU不合适。

希望收到你的来信。

致以最诚挚的问候