2017年11月1日，我成为Timeweb软件开发部门开发团队的负责人。 2018年11月12日，该部门负责人问何时准备好有关Habrahabr的文章，因为市场营销部门询问，志愿者已经结束，内容计划还需要其他内容）
因此，我想回顾一下我们产品的开发，测试和交付过程在过去一年中发生了什么变化。 关于旧版流程和工具，docker，gitlab以及我们的开发方式。
自2006年以来，Timeweb Hoster便已存在。 一直以来，公司一直在努力为客户提供独特而便捷的服务，以使其与竞争对手区分开来。 Timeweb拥有自己的移动应用程序，基于Web的电子邮件界面，虚拟主机控制面板，VDS，会员计划，其支持工具等等。
我们的gitlab中大约有250个项目：这些是客户端应用程序，内部工具，库，配置存储库。 他们中的数十个都得到了积极的开发和支持：他们在工作周内投入，测试，收集和发布它们。
除了大量的遗留代码外，所有这些都带来了适当数量的继承过程和相关工具。 像任何旧版一样，它们也需要维护，优化，重构，有时还要替换。
在所有如此丰富的项目中，控制面板最接近托管客户。 正是在“控制面板”项目中，我们最经常进行各种基础结构改进，并付出很多努力来保持互联基础结构的状态。 将获得的经验和喜欢的做法传播给其他产品及其团队。
我将告诉您过去一年中工具和流程的不同变化。
流浪者→docker-compose
问题
在第一个工作日，我试图在本地举起控制面板。 当时，一个存储库中有五个Web应用程序：
-PU虚拟主机3.0，
-PU VDS 2.0，
-PU网站管理员，
-STAFF（工具支持），
-准则（标准化前端组件的演示）。
要运行，请在本地使用Vagrant。 流浪汉发起了ansible。 要启动和配置它需要同事的帮助以及大约一天的清洁时间。 我必须安装特殊版本的Virtual Box（当前稳定版本中存在问题），在虚拟机内部的控制台上工作非常令人不安：诸如npm / composer install这样的琐碎命令大大降低了速度。
考虑到所使用的技术堆栈和计算机的功能，在虚拟机中应用程序本身的性能是不可能实现的。 更不用说虚拟机是虚拟机，并且从定义上讲，它占用了PC资源的很大一部分。
解决方案
本地开发环境已被重写为可以在docker容器中运行。 基于docker的容器化是在其生命周期的各个阶段隔离应用程序环境的最常见解决方案。 因此，没有特殊的选择。
结论
从优点：
-在本地，应用程序变得更加敏感，容器所需的资源少于VM，
-如实践所示，启动新实例仅需几分钟，并且只需要不低于某些版本的docker（-compose）即可。 克隆后，只需执行以下操作：
make install-dev make run-dev
有一些折衷方案：
-我必须为dockerized命令（composer，npm等）编写shell绑定。 与Vagrant相比，它们像docker-compose.yml一样，并不完全跨平台。 例如，在Mac上启动需要付出额外的努力，而在Windows下，使用docker在Linux虚拟机中运行发行版可能会更容易。 但这是可以接受的折衷，因为 该团队仅使用基于Debian的发行版，这对于商业开发是可以接受的限制，
-为了支持虚拟主机，基于
github.com/jwilder/nginx-proxy的容器在本地启动。 尽管这不会引起任何问题，但它并不是拐杖，而是有时需要记住的附加软件。
是的，团队中的每个人都必须至少了解一点Docker是什么。 尽管得益于上面提到的shell脚本和Makefile，开发人员无需考虑容器即可完成95％的任务，但可以保证他们拥有相同的环境。
newcp-dev→cp-stands
这些奇怪的短语分别是带有控制面板测试台（新旧）的机器的名称。
问题
Ansible配方仅在Vagrant内部使用，因此没有主要优势：产品和架子上的包装版本与开发人员所使用的不同。
旧机架上的服务器软件包版本与开发人员所拥有的版本不匹配，从而导致了问题。 由于系统管理员使用不同的配置管理系统，因此同步变得很复杂，并且无法将其与开发人员存储库集成。
解决方案
容器化之后，扩展docker-compose配置以在测试平台上使用并不困难。 已创建新机器以在DOCKER_HOST上部署支架。
结论
开发人员现在对本地环境和测试环境的相关性充满信心。
TeamCity→gitlab-ci
问题所在
TeamCity中的项目配置是一个艰苦而又忘却的过程。 CI配置与代码分开存储在xml中，该版本不适用于常规版本控制以及更改概述。 我们还遇到了TeamCity代理上构建过程的稳定性问题。
解决方案
由于gitlab已经用作存储库的存储库，因此开始使用它的CI不仅合乎逻辑，而且轻松愉快。 现在，整个CI / CD配置都在存储库中。
结果
在过去的一年中，TeamCity组装的几乎所有项目都安全地转移到了gitlab-ci。 我们有机会快速实施各种功能来自动化CI / CD流程。
管道的屏幕截图将是最明显的：
图 1.功能分支：包括所有可用的自动检查和测试。 完成后，发送带有指向redmine任务管道的链接的注释。 使用此分支组装和启动支架的手动任务。
图 2.使用代码冻结开发计划的构建（结帐：rc）：使用代码冻结按计划进行开发。 各个控制面板支架的图像组装是并行进行的。
图 3.标签管道：释放控制面板之一。 回滚释放的手动任务。此外，在gitlab-ci中，状态会发生变化，并且在进行中→复审→质量检查，在Slack中有关发布，更新阶段和回滚的通知中，将某人任命为Redmine。
这很方便，但是我们没有考虑一个方法论点。 在一个项目中实现了这种自动化之后，人们很快就习惯了。 而且，如果您切换到尚不存在或流程不同的另一个项目，则可以忘记在Redmine中移动并重新分配任务，或者留下带有“合并请求”链接（也使gitlab-ci）链接的评论，从而迫使查看者进行搜索先生你自己。 同时，您根本不想在项目之间复制.gitlab-ci.yml片段和随附的shell代码，因为您必须支持复制粘贴。
结论：自动化是好的，但是在所有团队和项目的水平上都一样-甚至更好。 我要感谢尊敬的公众关于如何很好地组织这种配置的重用的想法。
管道持续时间：80分钟→8分钟
逐渐地，我们的CI开始花费大量时间。 测试人员为此遭受了极大的痛苦：master中的每个修复程序都必须等待一个小时才能发布。 它看起来像这样：
图 4.pipeline 80 lvl分钟的持续时间。我不得不深入分析慢速位置几天，并寻找在保持功能的同时进行加速的方法。
在此过程中最长的时间是安装npm软件包。 毫无问题，他们用纱代替了它，并在几个地方保存了长达7分钟。
他们拒绝自动登台更新，而是首选手动控制此摊位的状态。
我们还添加了一些运行程序，并将并行的任务划分为应用程序映像的组装和所有检查。 经过这些优化后，在大多数情况下，更新所有展位的主分支管线开始花费7-8分钟。
Capistrano→部署者
为了在生产中和在Qa支架上进行部署，使用了Capistrano（在撰写本文时仍在使用）。 该工具的主要方案是：将存储库克隆到目标服务器并在其中执行所有任务。
以前，部署是由QA工程师使用Vagrant的必要ssh密钥触发的。 然后，随着流浪汉的遗弃，卡皮斯特拉诺搬进了一个单独的容器。 现在，使用Capistrano和gitlab-runners从容器中进行部署，并在必要的标签出现时自动标记有特殊的标签并具有必要的密钥。
这里的问题是整个构建过程：
a）大量消耗战斗服务器的资源（尤其是节点/ gulp），
b）无法使作曲家的npm版本保持最新。 节点等
在构建服务器（在本例中为gitlab-runner）上进行构建，然后将就绪的工件上传到目标服务器，这更合乎逻辑。 这将使战斗服务器免于组装实用程序和国外责任。
现在，我们考虑将部署程序替换为capistrano（因为我们没有任何红手，也不希望使用其DSL），并计划将程序集转移到gitlab端。 在某些非关键项目中，我们已经设法进行了尝试，到目前为止，它是令人满意的：它看起来更容易，我们没有遇到任何限制。
Gitflow：RC分支→标签
每周进行一次开发。 在五天的过程中，正在开发一个新版本：该开发版本接受计划于下周发布的改进和修补程序。 在星期五晚上，代码会自动冻结。 在星期一，将开始测试新版本，进行了改进，并在工作周中旬发布了该版本。
以前，我们使用名称形式为rc18-47的分支机构，这意味着发布候选版本是2018年的第47周。 代码冻结是为了检查开发中的rc分支。 但是在今年10月，我们改用了标签。 标记是在rc发行并与master合并之前，但实际上是在标记之后设置的。 现在，标签的外观可导致自动部署，冻结是将development转变为master的合并。
因此，我们在流程中摆脱了git和变量中的多余实体。
现在，我们将落后的项目“拉”到类似的工作流程中。
结论
流程的自动化，其优化以及开发是一个固定的问题：只要产品正在积极开发且团队正在工作，就会有相应的任务。 关于如何摆脱常规操作的新思路出现：功能在gitlab-ci中实现。
随着应用程序的增长，CI流程开始花费的时间令人无法接受，这是提高其性能的时候了。 由于方法和工具已经过时-您需要花一些时间进行重构，检查和更新。
