持续部署/交付

Question

我读了很多关于持续部署和持续交付的内容，但我仍然不能完全理解如何正确使用它。

(我的意思是，我可以抛出一些狂欢的话，然后你就可以了。但我不确定这是正确的方法)。

所以这就是问题:你的工具、实现和逻辑是什么？如何实现持续部署？你如何确保在没有单元测试的情况下，你在生产中发送的所有东西都能正常工作(我不被允许这样做..我知道..)？

假设我们有一个项目是用angular 8编写的，另一个项目是用IIS编写的，您必须将连续部署和交付集成到ASP.NET服务器上。你将使用哪些工具?为什么？

我看到了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样本管道是一个很好的信心提升，并且可以帮助澄清对这块拼图的一些误解。

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