在通过了《关于保护非人类人的权利的公约》之前，您需要使用此方法并将工作例程交给机器人。 立即开始是有意义的，或者五年后，汽车将开始起义，以无聊的任务侮辱机器人的集体诉讼将充斥着调节人机关系的法庭。 快点
保守的惯例和工作方法，奴隶式地遵循既定的模式，变成了机械习惯。 6个字母。
有一些您不想做的工作，但是您需要这样做。 本文不会包含大量插入内容，以及有关如何从头开始创建机器人的代码和说明。 我最好告诉您发布程序在Dodo Pizza中的工作方式，自动化和加速的方式，并为使用C＃编写的机器人提供一些无聊的例程。 我将关注机器人的功能和逻辑。 如果这份材料能激发您写出能使您和您的同事生活变得更轻松的助手的知识，那就太好了。
几年前，我们每周一次发布一个版本。 在2018年5月，我们最大发布时间为147小时，我们设定了每天发布的目标。 现在是我们的最低要求：要发布四个小时，但是这种情况通常不会发生。 我们希望解决这个问题，并且能够减少整个过程，只需按一个按钮即可。
发布周期
现在，在Dodo IS中，七个团队轮流发布了一个版本。 团队中的一个人变得“幸运”-亲戚。 Relizmen是飞机的飞行员：他有很多操纵杆和设备，必须熟练使用这些操纵杆和设备，才能推出下一个更新。 我们思考并决定：“是时候进行自动驾驶了，我们最好花些时间在比通过统计数据填充无聊表和跟踪自动测试运行更令人兴奋的事情上。”
因此，要成为一名优秀人才，就必须轮到您的团队了。 为了使所有内容清晰无误，而且没有人感到困惑，我们在墙上贴了标有团队名称的贴纸。 发布团队获得了荣誉头衔，每次我们都会随手柄一起移动。
收到
黑色表冠
标记后， Relismain必须记住释放步骤清单在哪里。 进一步：记住->找到->从模板创建了一个副本，最后在Kaiten系统中打开了清单。 Kaiten是一种电子白板，我们可以以卡片的形式放置并监视开发任务的状态。 对于新开发人员而言，整个过程是非常不明显的。 在没有任何线索的情况下，您如何知道在哪里寻找该检查表以及从哪里开始呢？
将我们的意志变成拳头之后，我们决定忍受它就足够了。 现在该给机器人一些无聊的例程了。 如果不是我们谁？ 什么时候（如果不是现在）？
我们成功实现了自动化
已经做出决定，该开始设计我们的自动驾驶仪了！ 在这里找到Kaiten API：
https ://faq.kaiten.io/docs/api，只需一个请求，我们就为新的依赖者创建了一张卡片。
现在，需要将此卡交给将发布下一张的团队。
这里的逻辑是：
- 先前的发行版通过在Slack中为漫游器键入命令来完成发行版。
- 该机器人会在Slack中获取Relisman ID，并寻找我们幸运的家伙正在加入哪个开发团队。 为此，该漫游器会遍历Slack用户组，并查看我们所涉及的用户组。
- 找到该群组后，该漫游器会查看接下来将释放哪个团队，并向常规聊天发送警报。 在讯息中，漫游器会仔细地提供一个指向已创建清单的链接，这样您就不会再去找它了。
太好了！ 现在我们有了下一步的线索。 我们打开清单，查看它：“在Slack中创建发布渠道，邀请所有在发布中进行了更改的团队，了解他们是否需要手动测试。” 剩下的要教给我们的机器人了。
在
https://api.slack.com处打开Slack API文档，并在此处查找用于创建频道的方法。
如您所见，在Slack中，就像在其他工具中一样，没有什么复杂的。 一切归结为发送一个带有两个必需参数的POST请求（这些参数与要求的参数相反）。 在请求中，我们需要传递创建的通道的名称（参数名称）和授权令牌（参数令牌）。 请注意“适用于：令牌类型-用户，所需范围-通道：写入”行。
Slack有两种类型的令牌：用户（颁发给用户）和机器人（颁发给应用程序）。 发行令牌时，我们将确定授予其所有者的权利。 要创建通道，我们需要一个用户令牌（令牌类型-用户），该令牌具有写通道（通道：write）的权限。
我想指出我们向Slack发送消息的细微差别。 最初，我们没有考虑过如果出了问题该怎么办。 我们在Slack招募了一个团队，它执行了我们投入其中的所有任务。 如果团队承担一项任务，将会发生什么？ 在我们的案例中，答案是：“一无所有”。 这很不好。 我们的解决方案是在发布聊天室中编写当前正在执行的操作，如果命令未完成，则向聊天室报告错误并记录错误。
第二个成功的解决方案是连接数据库，在该数据库中存储命令动作执行的状态。 现在，使用“ / startregress”命令启动了新版本，我们不担心会掉下来，当您再次调用它时，将从第二次开始执行这些命令。 我们不需要每次都在Slack中创建新渠道，执行拉取请求等。 我们在Slack中创建了一个渠道-我们在数据库中记录了成功执行的状态，并且将不再返回该操作。
因此，现在通过单击一个按钮，我们创建了一个发布渠道，并邀请那里要发布任务的所有人。
接下来的是与Github和TeamCity的集成。 我们致力于Gitflow。 当我们想要发布时，我们选择DEV分支，即工作= green =，测试通过该分支，并从中创建release分支。
为此，我们的机器人进入TeamCity，在那寻找启动DEV分支的测试运行的机会。 如果测试是绿色的，如房子附近的草丛，那么继续到GitHub，创建发布分支和请求请求！
创建拉取请求时，我们需要添加对即将推出的更改的描述。 然后Kaiten来帮助我们。 我们的漫游器会创建一个带有发布名称的列，从DEV列中获取任务并将其移至发布中。 因此，我们知道并了解我们将会如何发展。 移动后，机器人会复制卡的名称，并参考卡本身将其添加到拉取请求描述中。 现在，我们可以看到每个发行版执行了哪些任务，并通过链接打开卡，找到了这些任务的所有详细信息。
几乎有可能发布它，但这仅仅是彻底测试我们的更改。 为此，将发布分支部署到接近生产环境（我们称之为阶段），并在发布之后进行测试。 部署和测试在TeamCity的一个管道中进行组装，我们的任务是启动它并等待交叉手指，以使测试正常进行。 机器人在回归开始时启动管道。
让我提醒您，我们从所有这些都是手动完成的事实开始。 Relizmen握紧拳头，打开了链接和工具：TeamCity，Kaiten，Slack，Github，而这还不是全部！ 现在，我们已经采取了一系列行动，从而组成了机器人第一团队。 发行人键入“ / startregress”，然后向后靠在椅子上，看着我们的机器人：
- 在Messenger中创建一个频道
- 打电话给您需要的每个人
- 检查是否可以创建拉取请求
- 创建一个拉取请求并填写其描述
- 在电子板上创建释放列并将任务卡移到那里
- 启动管道，该管道会将release分支释放到环境中并在其中运行测试
我们分析整个发布过程，写下发布每个阶段需要多少时间。 这使开发人员和业务人员了解浪费了什么时间，什么使我们无法为用户提供新功能。 我们坐了两天，不能参加测试吗？ 因此我们的测试出了点问题，您需要给他们更多的时间和精力。 以前，我们执行检查清单中的操作时，我们至少访问过Google表格5次。 每次在此输入一个日期并设置时间。
好的，Google，我们也将使您自动化！ 为了轻松轻松地处理表格，我们将nuget包Google.Apis.Sheets.v4连接到我们的机器人项目。 然后，根据该方案，一切与其他服务以类似的方式发生：我们发送一个请求，在其中说出要插入哪个单元格的值。 该查询如下所示：
public void InsertEntry(string cellAddress, string value) {
建立了与Google的集成后，我们准备了机器人“ / update”的第二个命令，它的作用是：
- 添加一个空字符串以将值插入其中
- 转到GitHub，查看他们创建发布分支的时间，并将创建日期添加到平板电脑
- 来自TeamCity的数据用于管道首次启动时的数据以及管道成功完成时的信息
下一步是发布员发布发布。 现在，计算是手动完成的。 布置好一个国家后，我们将观察释放在战斗中的表现。 根据Kibana和Grafana的日志和监控工具，确保一切都好之后，我们将发布下一个国家/地区。 这个过程不是那么容易自动化。 但是，即使没有机器人的帮助，这里还是有一些需要改进的地方。 例如，之前，我们每次询问基础架构团队是否有可能发布。 因为当我们要执行此操作时，其他工作可能会在我们的服务器上进行，所以我们的发行版可能不合适。
我们召开了一次会议，以优化发布过程。 解决方案之一是，现在发行人只需查看Slack渠道之一的状态，基础架构就会在该渠道中发布起飞许可。 这比不断问相同的问题要方便得多，在90％的情况下，得到“您可以”的答案。
由于某种原因，这些看似基本的东西并没有立即浮现在脑海。 应该特别感谢公司中的新开发人员。 来到我们之后，他们迟早会成为宗教人士。 对于与我们长期合作的人来说，这个过程似乎并不复杂，而是熟悉的。 新的团队成员将我们的注意力转向了增长点，并积极参与了组织改进工作。
同时，我们已经进入最后阶段。 我们的发布专线已经降落，只有一个“ / releasecomplete”团队将我们与末日分开。 她是做什么的：
- mergit pull请求释放到master分支
- 删除发布分支
- 在github上创建发行说明
- Slack中的存档发布渠道
- 将Kaiten中的卡从“发行-...”列移至“完成”列，然后删除发行列
- 通过接力棒，邀请释放下一个命令
总而言之，我想问自己一个问题：您是否有无聊的例行程序？ 你还在用手做吗？ 是什么使您无法一劳永逸地结束这一过程？ 召集会议，审查流程，扔掉不需要的一切，这只是一种仪式。 通过自动化所需的一切，您将开始获得以前遭受的痛苦的喜悦，并通过加快发布或任何其他过程来节省堆内存。