我们正在制作一个用于开发的云项目，该平台可以尽可能简化开发人员，开发人员，测试人员，团队负责人和其他参与开发过程的专家的工作。 该产品现在不是现在，也不是明天，并且对它的需求正在形成。
主要思想是您可以使用预配置的工具来部署管道，但是同时可以进行许多设置，您所需要做的就是部署代码。
这种变态从何而来？ 我们看到一个明显的趋势，即新项目的部署速度现在会影响市场。 商业取决于发布的速度。 从漏洞修复的速度，到新漏洞的修复速度。 2018年初，全球公司“ 451 Research”对哪些技术将是优先发展进行了调查。 前十名包括容器创建和管理技术，以及无服务器应用程序架构和微服务，甚至超过了诸如区块链这样的炒作话题。
现在我们有几个问题要问您。
调查表：
有必要吗？
在开发新产品时使用容器有其优点和缺点。 必须根据设置的任务来决定是否使用该技术。 对于某些任务，不能放弃使用容器，对于某些任务，它们只是多余的。 例如，对于低流量的站点，两个服务器的简单体系结构就足够了。 但是，如果计划显着的发展增长，并在短时间内大量增加游客，那么在这种情况下，值得考虑使用容器的基础设施。
使用容器有几个优点：
- 每个应用程序都在其自己的容器中独立运行，从而最大程度地减少了与配置有关的问题。
- 通过隔离每个容器还可以实现应用程序安全性。
- 由于容器使用操作系统的内核，因此现在不需要来宾OS，因为这样可以释放大量资源。
- 另外，由于使用了操作系统的内核，并且由于您不需要依赖管理程序，因此与其他堆栈相比，容器需要的资源要少得多。
- 同样，由于容器不需要来宾操作系统，因此很容易将它们从一台服务器迁移到另一台服务器。
- 由于每个应用程序都在隔离的容器中运行，因此很容易将其从本地计算机转移到云中。
- 由于使用操作系统内核，启动和停止容器是非常“便宜”的。
结合以上所有内容，我们认为容器化技术是目前最快，最节省资源和最安全的堆栈。 由于容器的优点，您可以在本地机器和生产环境中拥有相同的环境，这有利于持续集成和持续交付的过程。
容器的好处是如此令人信服，以至于它们肯定会长期使用。
云与开发有什么关系？
在开发人员的理想世界中，只需单击一下按钮，任何提交代码都应投入生产，就像魔术一样。
我们这样处理：有一个带有任务和源的Gitlabchik。 当您需要收集东西时-GitLab Runner。 我们致力于Git Flow，所有功能都位于单独的分支上。 当分支进入存储库时，将在GitLab中启动对此代码的测试。 如果测试通过，则该线程的开发人员可以提出合并请求，实际上是进行代码审查的请求。 审查之后，分支被接受，合并到开发分支中，测试再次通过。 部署时，GitLab Runner会收集Docker容器并将其滚动到登台服务器，在该服务器上可以单击它并使它高兴。 这是第一个问题-我们用手检查代码以确保与功能的兼容性，这是我们修复的第一件事。 之后，我们将代码注入release分支。 对于她来说，我们正在推出解决方案的单独的生产前版本，我们的商业客户正在关注该版本。 在预生产版本上预安装该版本后，我们将其投入生产，然后滚动至产品节点。 有自动生成的发行说明和错误报告。 组装速度超过30分钟，现在降低了一个数量级。 我们为自己选择了一套工具，现在正在考虑如何制作相同的现成SaaS。
对于我们来说，典型的发布过程如下：
- 为实施新功能设定目标
- 代码本地化
- 根据任务进行更改。 在构建之前编写自动化测试。
- 代码验证，手动和自检
- 将代码合并到开发分支
- 建立一个开发分支
- 部署测试基础架构
- 在测试基础架构上部署发布
- 运行测试，功能，集成等。
- 如果有错误，请立即在开发分支中完成。
- 将dev分支迁移到master分支
这是一个详细说明我们过程的图：
其实，第一个问题-请告诉我们您在哪里耙什么耙，以及该方案有多普遍。 如果您使用的工作流程与此截然不同，请添加几句话，为什么这样做。
我们正在计划哪种产品？
我们决定在这方面不复制亚马逊，而是在考虑市场具体情况的情况下进行开发。 立即基于我们的分析保留所有计算是我们的主观意见。 我们欢迎进行建设性对话，并准备更改产品路线图。
在分析来自Amazon的现有管道时，我们得出的结论是，它具有巨大的功能，但重点是非常大的公司团队。 在我们看来，为了在Docker中推出微服务，它的时间过长，例如，如果在Kubernetes中推出，则更长，因为 这里有一个配置内部配置，定义内部协议等的地方。 所有这些都需要长期了解。
另一方面，例如有Heroku，您可以在其中一键部署。 但是由于通常情况下，项目与第三方微服务之间的关系十分繁琐，因此有时需要使用DBaaS服务推出自定义docker映像，而这一切都不适合Herocku，因为它们要么昂贵要么不舒服。
我们想找到另一个选择。 中庸之道。 根据项目和任务的类型，为您提供一组已经预先集成到单个管道中的预先配置的工具，同时保留设置发生重大更改的可能性以及替换工具本身的能力。
那会是什么呢？
生态系统，包括一个门户网站和一组工具和服务，以最大程度地减少开发人员与基础架构级别的交互。 您定义与物理环境无关的环境参数：
- 开发环境（配置管理系统，任务设置系统，用于存储代码和工件的存储库，任务跟踪器）
- CI-持续集成（组装，基础架构和业务流程）
- 质量检查-质量保证（测试，监视和记录）
- 登台-集成环境/预发布循环
- 生产-生产电路
在选择工具时，我们专注于市场上的最佳实践。
我们将使用带有并行功能尘埃的Docker和Kubernetes使用Stage和Prod构建基础架构。
这将反复进行-在第一阶段，计划了一项服务，该服务将使您能够从项目中获取Docker文件，然后收集所需的容器并将其布置到Kubernetes。
我们还计划特别关注用于监视开发过程和持续交付的服务。 我们所说的服务是什么意思？ 这是创建具有指标的分层KPI模型的机会，例如单元测试的覆盖率百分比，消除事件或缺陷的平均时间，从提交到交付的平均时间等。
从不同系统收集源数据-测试管理系统，任务管理，CI / CD组件，红外监视工具等
最重要的是要以适当的形式显示可用于快速分析的仪表板-可能进行深入分析的仪表板，指标的比较分析。
我们想做什么
实际上，我真的很想听听您关于所有这些以及我们的计划的信息。 现在他们是：
- 基础架构和编排-Docker和Kubernetes
- 任务设置，代码和工件存储，任务跟踪器-Gitlab，Redmine，S3
- 生产与开发-厨师/ Ansible
- 大会-詹金斯
- 测试-硒，LoadRunner
- 监视和记录-Prometheus和ELK
- 顺便说一句，您如何看待平台内是否会有选择-如果需要，选择了Jenkins，而不希望-GitLab Runner？
- 还是内部结构无关紧要，主要是所有东西都正确构建，测试和部署了？
有什么可以帮助？
该产品将为国内开发商开发。 如果您现在告诉我们该怎么做，它很可能会包含在发行版中。
请告诉我您现在正在使用什么堆栈。 您可以-在评论中或通过电子邮件发送至team@ts-cloud.ru。
UPD：为方便起见，我们在Google表格中做了一个简短的问卷调查-
这里 。
此外，我们将为您提供最新的开发信息-在某些时候，我们将为协助参与者提供beta（实际上，可以免费访问云的良好计算资源以换取反馈）。