需要什么才能安全地使非技术用户触发自动部署？

Question

背景

我有个朋友(不，真的！)这位朋友在IT和终端用户之间工作。就像一个商业分析师或顾问。这位朋友没有技术或IT背景。他们已经对软件和系统有了很高的理解，但是，例如，他们不能读/写代码，也不能对软件的底层细节进行对话。

我朋友的公司已经安装了连续集成(CI) /连续交付(CD)管道来构建和部署他们的软件，但是这些管道必须手动触发。

我的朋友被要求负责触发非生产环境和生产环境中的自动部署管道。这样做的过程在技术上是简单而快速的：

• 登录到自动化软件
• 选择适当的CD管道作业
• 选择一对配置值(要部署到的环境，要部署的软件工件)
• 按下按钮触发作业

部署

，还是不部署

我的朋友不愿意接受这一责任，尽管这个过程本身对他们来说并不困难。

我是一名软件工程师，负责在我的公司触发类似的自动化部署，我不愿意把这一责任交给像我朋友这样的技术含量较低的用户。然而，我们都很难说出是什么让我们感到不舒服，我们也不确定自己是不是不讲理。

，到底有什么大不了的？

当我作为一名软件工程师执行触发自动部署的过程时，我所做的不仅仅是触发工作。

我熟悉已经部署的工件与正在部署的工件之间的代码更改(如果我还不熟悉的话)。我评估这些变化的范围和风险。我评估这些变化对系统和依赖系统的影响。如果在上述步骤中，我确定了任何风险领域，我准备在必要时对这些具体项目作出反应。据我所知，我对是否继续部署作出最后判断。

一旦触发部署作业，就会监视状态。如果作业失败，我首先确认自动回滚是成功的，并且应用程序/系统没有受到影响。然后我开始对作业失败进行初步分析和故障排除，以及是否需要进行另一次尝试，或者是否需要首先采取行动。

在任务成功完成后，我将对部署过程和软件运行状况执行一些明智的检查。

我对代码、自动化部署过程执行的每一步以及系统基础结构和体系结构都非常了解。这些知识为我的决定提供了依据。

现在，我将是第一个承认--很多东西可以是自动化的，或者是在我按下按钮之前就内置到变更管理过程中的。在一个理想的世界里，整个过程可以是完全自动化和连续的--不需要人类。

尽管如此，我不认为我朋友的公司目前有一个改变的管理过程或自动化来处理所有这些。

TL；

博士

允许非技术、非IT用户管理软件构件的自动化部署(无论是在非生产环境还是在生产环境中)所需的内容。为了使这一过程安全可靠，必须设置哪些安全防护装置？还是无论如何这都是个坏主意？

Answer 1

实际上，这不仅仅是启动管道作业。

如果作业失败，我们如何知道是来自工件的错误、资源短缺，还是依赖服务的短暂错误？

如果部署成功，但稍后对服务的实际调用失败怎么办？我们应该如何针对这个问题，以及如何知道我们需要回滚的工作的哪一部分？

这些都是技术部分。

Answer 2

你的问题包含了部分答案。必须对非技术人员的部署进行自动监测和回滚。基本上，这意味着您在监视部署时所做的工作负载的自动化。当然，这种自动化不会涵盖所有可能的场景，而是增加了成功的确定性。它还涉及到交付这种解决方案的额外费用。人们可能希望估计历史数据上可能存在的风险，比如“由于该子系统，该系统每两个月中断一次”。这种评估将说明自动化的实现和依赖有多容易或有多难。另外，还可能需要编写升级策略来支持该人员。

Answer 3

您需要某种类型的审批系统，以便技术人员和业务人员能够了解将部署什么、何时部署，以及它对更广泛的技术生态系统产生什么影响。您的朋友只需“批准”部署。一旦所有的批准都被记录下来(并获得批准)，那么自动构建系统就应该在预定的时间开始部署。

部署，即使是按下按钮，也需要密切的技术知识。这并不是说按下按钮需要专业知识，但正如您所说的，失败场景是复杂的。部署前后需要进行多种检查。有些是手动的。大多数都是自动化的。

这就是为什么许多DevOps风格的工具都内置到他们的按钮部署系统中。我当然可以按下按钮。当然，我可以退回去，而且我知道这不会影响到其他系统。最终用户希望我现在就部署这些更改吗？审批制度为每一个参与的人提供了这种透明度。

底线是:非技术人员自己部署软件是不安全的。你需要与技术人员和商人沟通。审批系统为您提供了此通信渠道。