DevOps 团队搭建
- 产品负责人：业务方面的代表，可以把他想象成客户。
- 开发团队：负责具体功能开发。
- QA 团队：负责质量保障。
- 运维团队：维护生产环境，配置，发布。
- 信息安全团队：负责系统和信息的安全
团队价值流
工作在线
如果说要让团队站在同一个平面上面，使用高效的工具是必不可少的。例如：Confluence，石墨文档，Jira，禅道，ProcessOn，Jenkins，Bamboo，Git，JMeter，LoadRunner。
它们可以帮助我们从设计，开发，测试，发布各个阶段提升工作效率。让团队保持高度统一，让所有的工作都在线
让工具为团队服务，让工作在线
DevOps 流水线
提交阶段：是从技术角度上判断系统是可以工作的。这个阶段会进行编译，运行单元测试脚本，通常这些脚本都是程序员自己编写的
另外，会针对具体代码，由经验丰富的程序员做代码走查，或者代码互查。这里可以使用 Junit 单元测试工具
自动化验收测试阶段：是从功能和非功能角度上断言整个系统是可以工作的，即从系统行为上看，它满足用户的需要并且符合客户的需求规范
手工测试阶段：用于判断系统是可用的，满足了它的系统要求，试图发现那些自动化测试未能捕获的缺陷，这部分测试内容较为复杂，步骤较多，甚至存在多系统切换的情况。
这一阶段通常包括探索性测试、集成环境上的测试以及 UAT(User Acceptance Testing，用户验收测试)。测试人员会根据 UAT 的用例对系统进行测试
发布阶段：旨在将软件交付给用户，是直接将其应用部署到生产环境，部署之后就进入运维阶段。
按照流水线部署的好处就是，控制每个阶段的交付质量，逐步建立交付者的信心，通过层层筛选将问题挡在外面。
同时对于开发，测试，运维人员也是考验。他们需要大量的协同工作，不断地让应用在流水线上流动，并且及时反馈给不同位置上的队员。
在熟悉了流水线上的几个阶段以后，再来看看每个阶段产生了哪些数据，以及这些数据是如何流动的
①流程的起点是，开发人员向代码库提交代码。在 Checkin 代码之前，开发人员需要把代码库中相关的代码和组件下载到本地，保证修改后的代码在本地是可以编译通过的。
比较规范的公司，是需要申请 Code Review，让其他的同事走查代码。虽然在 Checkin 到代码库之后，平台会自动运行单元测试。但是建议各位，先做单元测试。
因为，一旦进入验收阶段，编译会花费大量的时间，如果出现问题，系统会生成错误报告并且发给 Team Leader 或者项目组。
如果那个时候再改代码，恐怕所有人都知道 Bug 是从你这里出来的了。因此，还是先在本地跑一下单元测试。
其范围包括你修改代码的模块，也包括其他模块。实际上，任何对代码的修改都有可能影响其他模块，即使你并没有修改其他模块。
持续集成管理系统对这次代码提交作出响应，从指定的代码库拉取代码，并且进行编译，运行单元测试，执行代码分析，组装打包。
如果单元测试都通过，并且代码符合编码标准，就可以打包成可执行文件，并放到一个成品库(artifact repository)中。
当下的持续集成服务器，都提供这些功能，并让用户和流水线的后续阶段能以简便的方式进行。
另外，还有像 Nexus 和 Artifactory 这样的工具可帮助管理过程产物。目前比较成熟的产品。例如 Bamboo，Jenkins 都可以通过配置代码库，成品库，通过脚本命令的方式完成上述操作
②第二个阶段通常由运行时间较长的自动化验收测试。这些测试的主要内容，是针对一些 API 和模块的测试。
也有的项目组用来做页面的测试，但是个人不建议做页面的自动化，特别是在页面设计的初期，页面元素经常变动，自动化的脚本变化也很大，效果不是很好。
在此之后，部署流水线可能会有分支出现，这样就可以将该构建版本独立部署到多个不同的环境中，比如部署到用户验收测试环境、容量测试环境和生产环境。
也有串行的例子，比如 DEV(开发)环境，INT(集成测试)环境，MO(准生成)环境，Prod(生产)环境。
通常情况下，我们希望测试人员或运维人员可以做到自服务，即自己手工选择需要的某个版本。
例如：可以通过 Bamboo 或者 Jenkins 工具选择成品库中的应用版本，然后发布到指定的环境。
所谓的自动化部署脚本也就是一行能够在服务器上运行的命令，执行命令完成部署工作。
测试人员应当能够看到需要手工测试的所有构建版本，以及它们的状态，之后单击一个按钮，运行相应的部署脚本将选定的构建版本部署到选定的环境上
