在Devops岗位已经工作了差不多5年的时间，期间也遇到了许多的问题，很久没有写过博客来回顾一下这5年的工作经历了，趁现在闲来无事记录一下我眼中的软件生命周期。
几个人的软件
当我大学刚毕业的时候，有一段时间和同学一起做了一个很简单的网站，当时我们4个人一起开发，网站做的也很简单，整个软件的开发周期是这样的。
- 代码简单的用svn来管理，没有明确的版本管理，大家都一股脑的往一个分支里面提变更。
- 开发完的功能只是在本地简单的测试了一下
- 测试完成的软件也只是简单的打了一个war包，然后上传到远程的服务器中
- 远程服务器用的简单的tomcat服务，并使用IIS做代理（IIS是微软的一个web服务组件）
上面所有的过程都是手动的。在此期间我们遇到了很多问题:
- 提交代码的时候常常会遇到代码冲突的情况，也遇到自己把别人代码覆盖亦或是自己代码被别人覆盖。
- 上线的网站往往没有经过更多的测试出现Bug或者崩溃的情况。
- 由于并没有任何的负载均衡，所以网站一旦崩溃就完全无法访问了。
- 所有的操作都是手动的，包括服务器的搭建，如果服务器崩溃，手动从头来应该是件很痛苦的事情（虽然这不是一个问题）。
但是对于上面这些问题，对于一个简单的应用来说，应该都很还好，无法想象如果一个团队在开发一个大的应用会成为什么灾难。
团队开发的软件
当成为Devops后，常常会从上帝视角来看待整个软件产品的开发，为了保证十几人，几十人甚至上百人的团队有效的开发产品，我们不得不重新审视整个软件的生命周期。 对于我来说Devops的所有工作都是为了让软件的开发和部署变的没有那么的完全格格不入，并且尽可能的保证软件快速迭代的同时也保证产品在线上的稳定运行。
以下是我对整个团队协作开发应用的软件生命周期的一个简单的概括，对于每一个环节我认为都可以写一篇文章来进行详细的阐述：
- 团队成员用统一的版本管理工具来维护产品的源代码，并保证代码的历史可溯性。
- 团队成员应该尽可能的保证自己的功能代码的可测试性。
- 通过CI工具将这些测试的流程自动化并作为代码合并的指标。
- 代码合并后的应用通过CD工具应该部署在一个沙盒环境中进行统一的集成测试。
- 集成测试的结果应当作为是否能发布到产线环境的标准之一。
- 通过CD工具将测试通过的应用自动的发布到产线环境中。
- 通过监控数据实时的采集产线的指标并生成报告供工程师团队参考。
- 通过监控设置的告警也要及时的在产品有问题的时候告知给工程师团队（要优先于客户提出问题）。
在这里所有的流程其实也是为了解决我之前提到几个人开发软件时候遇到的一些问题。这对大型团队来说尤为重要，这关系到整个软件开发，部署的可持续性和可迭代性