我读了很多有关持续部署和持续交付的内容，但是我仍然不能完全理解如何正确使用它。
（我的意思是，我可以抛出一些bash，然后就可以了。但是我不确定这是正确的方法）。
所以这是一个问题： 您的工具，实现和逻辑是什么？您如何实施持续部署？
>如何确保生产中发送的所有内容在没有单元测试的情况下都能正常工作（我不允许这样做。..我知道..）？假设我们有一个用角度8编写的项目，用ASP.NET Framework编写了一个项目，您必须将持续部署和交付集成到IIS服务器。 您将要使用哪些工具，为什么？
我看到了TeamCity，Jenkins，Gitlab CI / CD，Azure等。但是对我来说，它们似乎都不是正确的选择（可能是因为我的持续部署/交付命令/业务逻辑很差）。
现在，让我们假设您也必须更新数据库。您可以使用sqlpackage和dacpac来做到这一点。是的，但是假设您已经在上一步中部署了“服务器”应用程序，并且由于架构存在一些问题，因此数据库未更新。你的表现如何？
很抱歉有这么长的帖子以及那些（愚蠢的？）问题，但是我正在尝试学习如何正确使用它，但不幸的是，我是公司中唯一的开发人员。
答案 0 :(得分：0)
这里有很多东西需要解压。除了个别叙述之外，持续部署和交付本身就是一个强大的主题。
通过将软件交付实践 (CI/CD) 与其实现（Jenkins、TeamCity 等）和工具（服务器、数据库、框架等）分开来考虑它可能会有所帮助。至少要理解三种不同类型的野兽。
CI/CD 的存在是为了帮助企业降低风险并通过不断迭代地将软件交付给用户来尽快向客户学习。 CI/CD 非常成功，如果他们的工程师尽可能多地利用实施这些实践的现有服务，公司将受益匪浅。
Jenkins/TeamCity、AWS/DigitalOcean 和所有这些其他类型的服务都知道他们在做什么，因此您可以或多或少“简单地”将代码交给他们——假设一切都正确设置——他们会拉代码，运行测试（如果希望存在，否则有什么意义），构建项目并将其发送到生产环境。这适用于“富人”或“穷人”、大小、复杂或简单类型的应用程序，它确实与项目的感知状态无关。
因此，采用最简单的选项并跳过箍以完成所有设置是需要采取的一步。为了快速开始，有时人们对每件事的细节了解得越少，采取的步骤越小，可能就越好；因此，使用“Hello World”类型的应用程序和虚拟单元测试（因为为什么不）设置 CI/CD 示例管道是一个很好的信心提升，可以帮助澄清对该难题的一些误解。
然后，一旦它不再碍事，使用特定的工具、选择的框架、最喜欢的技术以及诸如此类的东西就成为要解决的问题的另一部分。