code review
在敏捷中，质量提升是需要全员参与的。
为什么执行 review
- 代码评审可以及时发现一些容易发现的 BUG，而不必将发现 BUG 的时间点推迟到测试阶段。
- 代码评审可以保证至少有两个人都理解任何一份代码。当出现员工休假、离职等情况的时候，至少保证团队的代码不会陷入无人理解或者无人处理的状况。
- 代码评审的最大好处是纯社会性的，当你知道你的每一行代码都有另外一个人看，自然会更加卖力的表现，拿出最好状态的编码。
代码评审的流程有以下两种：
提交前评审(pre-pushcode review)
- 程序员在试图提交代码变更到代码库之前，先提交变更申请，变更申请包含了这次变更的内容；
- 评审人查看变更内容，评估变更，与变更申请人沟通，评审人评估是否通过变更；
- 如果评审人通过变更，则变更申请人才可以提交代码到代码库；
- 如果评审人不通过变更，则变更申请人需要根据讨论结果或评审建议做出修改，直到与评审人达成一致，通过评审，才可以提交代码到代码库。
提交后评审(post-pushcode review)
- 程序员提交变更代码到代码库；
- 评审人审查这次变更的内容，如果评审通过，则标记此次的变更已审查；
- 如果评审人有疑义，则与变更人沟通，变更人根据讨论结果或评审意见做出修改，直到与评审人达成一致，通过评审。
提交前评审的好处
- 程序员会更积极的将变更的代码组织的更好，更模块化，更容易阅读；
- 评审人有机会在代码提交之前发现问题，或给出更好的建议，对应的程序员对这样的反馈更容易接受；
- 评审人给出建议或意见之后，相比提交后评审，程序员会更加积极的最反馈做出响应；
- 评审人会更加认真的对变更进行评审，并且发现问题后会更加积极的参与讨论，对发起变更的程序员提供支持；
- 在真正提交变更前发现问题并予以解决显然比提交后再进行评审，然后提交修改补丁更好；
提交后评审的好处
- 提交后评审更加容易实施，过程对现有的组织架构和流程没有完全的颠覆，对团队成员的要求没有那么高；
- 相比提交前评审，提交后评审不需要对修改代码，提交变更这个过程中断，不需要等待评审的时间；
- 可以作为组织向提交前评审过程实施的过渡训练；
常用工具
Phabricator、 Review Board、gitlab等
代码静态分析
代码静态分析（Program Static Analysis）是指在不运行代码的方式下，通过词法分析、语法分析、控制流、数据流分析等技术对程序代码进行扫描，验证代码是否满足规范性、安全性、可靠性、可维护性等指标的一种代码分析技术。
代码静态分析可以在开发阶段就找到一些 bug，尤其是黑盒测试难以发现的 bug，如资源未释放等。
代码静态分析的特点
- 不实际执行程序。动态分析是通过在真实或模拟环境中执行程序进行分析的方法，多用于性能测试、功能测试、内存泄漏测试等方面。静态分析不运行代码，只是通过对代码的静态扫描对程序进行分析。
- 执行速度快、效率高。目前成熟的代码静态分析工具每秒可扫描上万行代码，相对于动态分析，具有检测速度快、效率高的特点。
- 误报率较高。代码静态分析是通过对程序扫描找到匹配某种规则模式的代码从而发现代码中存在的问题，这样有时会将一些正确代码定位为缺陷的，因此静态分析有时存在误报的缺陷，可结合动态分析方法进行修正。
代码静态分析的工作内容
- 类型检查
- 风格检查
- bug 查找
- 安全漏洞检查
代码静态分析的时机
- 在编码时检查，在IDE中集成对应的插件
- 编码完成后统一检查
常用工具
Pclint，checkstyle，pmd，findbugs，hp fortify，sonarqube
CI/CD
持续集成（ContinousIntergration，CI）
持续集成是一种软件开发实践，即团队开发成员经常集成它们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的编译、发布、自动化回归测试来验证，从而尽快地发现集成错误。许多团队发现这个过程可以大大减少集成的问题，让团队能够更快的开发内聚的软件。持续集成是为了持续交付。没有单元测试的持续集成基本无意义。
持续部署（ContinousDelivery，CD）
在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境中。比如，我们完成单元测试后，可以把代码部署到测试环境中，交付给质量团队或者用户，以供评审。如果评审通过，代码就进入生产阶段。
对于测试最大的好处是节约时间！
一个常规的测试过程：开发送测一个版本—测试人员从配置库下载版本—编译版本—部署到测试环境—进行冒烟测试—进行功能测试。
而这些过程完全可以由CI/CD来替代。
DevOps
DevOps 是一个完整的面向 IT 运维的工作流，以 IT 自动化以及持续集成（CI）、持续部署（CD）为基础，来优化程式开发、测试、系统运维等所有环节。
目标：
让生产端变得敏捷起来！
DevOps实际是一种文化上的变迁，代表了开发、运维、测试等环节之间的协作，因此DevOps工具是非常多种多样的，甚至可以由多种工具组成一个完整的DevOps工具链。
此类工具可以应用于一种或多种类别，并可体现出软件开发和交付过程的不同阶段：
- 编码：代码开发和审阅，版本控制工具、代码合并工具
- 构建：持续集成工具、构建状态统计工具
- 测试：通过测试和结果确定绩效的工具
- 打包：成品仓库、应用程序部署前暂存
- 发布：变更管理、发布审批、发布自动化
- 配置：基础架构配置和部署，基础架构即代码工具
- 监视：应用程序性能监视、最终用户体验
工具：
- 版本控制&协作开发：GitHub、GitLab、BitBucket、SubVersion、Coding、Bazaar
- 自动化构建和测试：Apache Ant、Maven 、Selenium、PyUnit、QUnit、JMeter、Gradle、PHPUnit
- 持续集成&交付：Jenkins、Capistrano、BuildBot、Fabric、Tinderbox、Travis CI、flow.ci Continuum、LuntBuild、CruiseControl、Integrity、Gump、Go
- 容器平台：Docker、Rocket、Ubuntu（LXC）、第三方厂商如（AWS/阿里云）
- 配置管理：Chef、Puppet、CFengine、Bash、Rudder、Powershell、RunDeck、Saltstack、Ansible
- 微服务平台：OpenShift、Cloud Foundry、Kubernetes、Mesosphere
- 服务开通：Puppet、Docker Swarm、Vagrant、Powershell、OpenStack Heat
- 日志管理：Logstash、CollectD、StatsD
- 监控，警告&分析：Nagios、Ganglia、Sensu、zabbix、ICINGA、Graphite、Kibana
