CI CD
What is Continuous Integration?
Continuous Integration (CI) is a development practice where developers integrate code into a shared repository frequently, preferably several times a day. Each integration can then be verified by an automated build and automated tests. While automated testing is not strictly part of CI it is typically implied.
One of the key benefits of integrating regularly is that you can detect errors quickly and locate them more easily. As each change introduced is typically small, pinpointing the specific change that introduced a defect can be done quickly.
In recent years CI has become a best practice for software development and is guided by a set of key principles. Among them are revision control, build automation and automated testing.
Additionally, Continuous Deployment and Continuous Delivery have developed as best-practices for keeping your application deployable at any point or even pushing your main codebase automatically into production whenever new changes are brought into it. This allows your team to move fast while keeping high quality standards that can be checked automatically.
CI带来的一个最大的益处不是仅仅自动的构建，减少手动操作的时间，而是能尽快的发现错误。因为是自动的构建，所以构建的成本低，即使没有自动化的测试，每次小的改动都能够快速部署，如果发生问题，那就是这次改动造成的，能够很快的发现问题。而有了自动化的回归测试，这就更能发挥优势，新的小的改动对于以前功能的影响能够自动的发现。
Solve problems quickly
Because you’re integrating so frequently, there is significantly less back-tracking to discover where things went wrong, so you can spend more time building features.
Continuous Integration is cheap. Not integrating continuously is expensive. If you don’t follow a continuous approach, you’ll have longer periods between integrations. This makes it exponentially more difficult to find and fix problems. Such integration problems can easily knock a project off-schedule, or cause it to fail altogether.
Continuous Integration brings multiple benefits to your organization:
- Say goodbye to long and tense integrations
- Increase visibility enabling greater communication
- Catch issues early and nip them in the bud
- Spend less time debugging and more time adding features
- Build a solid foundation
- Stop waiting to find out if your code’s going to work
- Reduce integration problems allowing you to deliver software more rapidly
以上，持续集成带来的好处还有，减少等待漫长和紧张的集成时间，更早的发现问题，出现问题时候能够较少debug时间，能够尽早的交付软件。
还有个特别的，感受颇深，不用每次上线后花很长时间验证以前的功能是否可用。
“Continuous Integration doesn’t get rid of bugs, but it does make them dramatically easier to find and remove.”
上面这句，引用Martin Fowler，这大神好像也是DDD那书的作者。
由于CI带来的在一次小的改动都能够去集成测试，如果发现问题，那么问题就是在这次小的改动中，能更早发现问题，更容易解决问题。
Continuous Delivery vs Continuous Deployment
We decided to call the book Continuous Delivery for a few reasons. First of all, there’s the somewhat pedantic fact that deployment does not imply release. As we say in the book, you can continuously deploy to UAT - no big deal. What makes continuous deployment special is deploying every change that passes the automated tests (and optionally a short QA gate) to production. Continuous deployment is the practice of releasing every good build to users - a more accurate name might have been “continuous release”.
While continuous deployment implies continuous delivery the converse is not true. Continuous delivery is about putting the release schedule in the hands of the business, not in the hands of IT. Implementing continuous delivery means making sure your software is always production ready throughout its entire lifecycle - that any build could potentially be released to users at the touch of a button using a fully automated process in a matter of seconds or minutes.
关键词-“deployment does not imply release”，“ Continuous delivery is about putting the release schedule in the hands of the business, not in the hands of IT. ”。
持续交付不是迭代的把做好的包交付给客户或者IT，而是需要做到：
software is always production ready throughout its entire lifecycle - that any build could potentially be released to users at the touch of a button using a fully automated process in a matter of seconds or minutes.
作者还抛出了另外一个问题，如何说是做完了一个store？
what does it mean to be “done” with a story?
- You have run your entire test suite against the build containing the story.
- The story has been demonstrated to customers from a production-like environment.
- There are no obstacles to deploying to production.
回归测试，新的case要完成；需要在预览环境（“production-like”）进行demonstrated；部署到生产环境不具备任何障碍；
Continuous Delivery maturity matrix
和软件成熟度模型一样，CD也有自己的成熟度模型，这里有个checklist： CD_Checklist，还有个简明的图：
Build
- Common nightly build
- CI server builds on commit
- Build from VM 与 CI server orchestrate VMs
Test + QA
基本都没实现，好像只做了Peer-reviews。怎么说，technical debt。
SCM
用git，特性拉分支，基本做到了advanced
Visibility
基本没做。
参考
CONTINUOUS INTEGRATION ESSENTIALS
CONTINUOUS INTEGRATION
Continuous Delivery vs Continuous Deployment
持续交付相关blog