持续部署/交付

Question

我阅读了很多关于持续部署和持续交付的信息，但我仍然无法完全理解如何正确使用它。
（我的意思是，我可以抛出一些 bash 行，然后就可以了。但我不确定这是正确的方法）。

所以这是一个问题： 你的工具、实现和逻辑是什么？您如何实施持续部署？ 您如何确保您在生产中发送的所有内容在没有单元测试的情况下都能正常工作（我不允许这样做..我知道..）？

假设我们有一个用 Angular 8 编写的项目和一个用 ASP.NET Framework 编写的项目，您必须将持续部署和交付集成到 IIS 服务器。 您将使用哪些工具以及为什么？

我看到了 TeamCity、Jenkins、Gitlab CI/CD、Azure 等。但它们似乎都不是我的正确选择（可能是因为我的持续部署/交付命令/业务逻辑很差）。

现在假设您还必须更新数据库。您可以使用 sqlpackage 和 dacpac 来执行此操作。是的，但是假设您已经在上一步中部署了“服务器”应用程序并且数据库没有更新，因为模式存在一些问题。你的表现如何？

很抱歉这篇很长的帖子和那些（可能是愚蠢的？）问题，但我正在努力学习如何正确使用它，不幸的是我是我公司中唯一的开发人员..

Answer 1

这里有很多东西要解压。除了个人叙述之外，持续部署和交付本身就是一个强大的主题。

通过将软件交付实践 (CI/CD) 与其实现（Jenkins、TeamCity 等）和工具（服务器、数据库、框架等）分开来思考可能会有所帮助。至少要理解三种不同类型的野兽。

CI/CD 的存在是为了帮助企业降低风险并通过不断迭代地将软件交付给用户来尽快向客户学习。 CI/CD 非常成功，如果公司的工程师尽可能利用现有的服务来实施这些实践，公司将受益匪浅。

Jenkins/TeamCity、AWS/DigitalOcean 和所有这些其他类型的服务都知道他们在做什么，因此您可以更“简单”地将代码交给他们 - 假设一切都正确设置 - 他们会拉代码，运行测试（如果希望存在，否则有什么意义），构建项目并将其交付生产。这适用于“富”或“穷”、大或小、复杂或简单类型的应用程序，它确实与项目的感知状态无关。

因此，使用最简单的选项并跳过障碍来完成所有设置是需要采取的一步。为了快速开始，有时人们对每件事的细节了解得越少，采取的步骤越小，效果就越好；因此，使用“Hello World”类型的应用程序和虚拟单元测试（因为为什么不）设置 CI/CD 示例管道可以很好地提高信心，并有助于澄清对这部分难题的一些误解。

然后，一旦解决了问题，使用特定工具、选择的框架、最喜欢的技术等等就成为要解决的问题的另一部分。