8 Principles of Continuous Delivery -- 持续交付的8个原则, 来自jamesbetteley

来源:互联网 发布:新型网络犯罪案例分析 编辑:程序博客网 时间:2024/03/29 20:29


http://jamesbetteley.wordpress.com/2011/08/04/continuous-delivery/ 

8 Principles of Continuous Delivery

  1. 发布和部署的过程必须是可重复和可靠的;这个会导致第二个原则---The process for releasing/deploying software MUST be repeatable and reliable. This leads onto the 2nd principle…
  2. 100%自动化! 因为手工部署永远不可重复和可靠!Automate everything! A manual deployment can never be described as repeatable and reliable (not if I’m doing it anyway!). You have to invest seriously in automating all the tasks you do repeatedly, and this tends to lead to reliability.
  3. 困难的或者艰难的事情,多做了就会变得容易!因为你做的多了,就会了解,就会提高;打个比方你每天都在干的事情,你会觉得困难么? If somethings difficult or painful, do it more often. On the surface this sounds silly, but basically what this means is that doing something painful, more often, will lead you to improve it, probably automate it, and this will eventually make it painless and easy. Take for example doing a deployment of a database schema. If this is tricky, you tend to not do it very often, you put it off, maybe you’ll do 1 a month. Really what you should do is improve the process of doing the schema deployments, get good at it, and do it more often, like 1 a day if needed. If you’re doing something every day, you’re going to be a lot better at it than if you only do it once a month.
  4. 任何东西都需要进版本库,进行有效的版本控制;Keep everything in source control – this sounds like a bit of a weird one in this day and age, I mean seriously, whodoesn’t keep everything in source control? Apparently quite a few people. Who knew?
  5. 好了意味着发布成功; 只要没有完全发布成功,就不算完;你的代码进库了,build了,测试过了,可是只要没有发布成功,你就得继续努力;Done means “released”. This implies ownership of a project right up until it’s in the hands of the user, and working properly. There’s none of this “I’ve checked in my code so it’s done as far as I’m concerned”. I have been fortunate enough to work with some software teams who eagerly made sure their code changes were working right up to the point when their changes were in production, and then monitored the live system to make sure their changes were successful. On the other hand I’ve worked with teams who though their responsibility ended when they checked their code in to the VCS.
  6. 质量考量要过关!质量不过关,相应的质量指标不合格,也是不行的;Build quality in! Take the time to invest in your quality metrics. A project with good, targeted quality metrics (we could be talking about unit test coverage, code styling, rules violations, complexity measurements – or preferably, all of the above) will invariably be better than one without, and easier to maintain in the long run.
  7. 项目组每个让人对发布流程都有责任!开发人员写code的时候就需要想着我这个code该怎么部署;项目经理计划项目的时候就应该关注部署相关的问题;测试人员需要尽可能多的测试部署相关的场景,就像测试代码一样认真!Everybody has responsibility for the release process. A program running on a developers laptop isn’t going to make any money for the company. Similarly, a project with no plan for deployment will never get released, and again make no money. Companies make money by getting their products released to customers, therefore, this process should be in the interest of everybody. Developers should develop projects with a mind for how to deploy them. Project managers should plan projects with attention to deployment. Testers should test for deployment defects with as much care and attention as they do for code defects (and this should be automated and built into the deployment task itself).
  8. 持续改善!永远记得努力提高你的系统已达到更好的易用性和可靠性!Improve continuously. Don’t sit back and wait for your system to become out of date or impossible to maintain. Continuous improvement means your system will always be evolving and therefore easier to change when needs be.

To go with these principles there are also:

持续交付的4个实践 : 4 Practices of Continuous Delivery 

  1. 仅仅build一次二进制文件, Build binaries only once. You’d be staggered by the number of times I’ve seen people recompile code between one environment and the next. Binaries should be compiled once and once only. The binary should then be stored someplace which is accessible only to your deployment mechanism, and your deployment mechanism should deploy this same binary to each successive environment…
  2. 使用相同的机制来部署任一环境;Use precisely the same mechanism to deploy to every environment. It sounds obvious, but I’ve genuinely seen cases where deployments to QA were automated, only for the production deployments to be manual. I’ve also seen cases where deployments to QA and production were both automated, but in 2 entirely different languages. This is obviously the work of mad people.
  3. 部署需要做冒烟测试 Smoke test your deployment. Don’t leave it to chance that your deployment was a roaring success, write a smoke test and include that in the deployment process. I also like to include a simple diagnostics test, all it does it check that everything is where it’s meant to be – it compares a file list of what you expect to see in your deployment against what actually ends up on the server. I call it a diagnostics test because it’s a good first port of call when there’s a problem.
  4. 有任何失败,立马停止, If anything fails, stop the line! Throw it away and start the process again, don’t patch, don’t hack. If a problem arises, no matter where, discard the deployment (i.e. rollback), fix the issue properly, check it in to source control and repeat the deployment process. A lot of people comment that this is impossible, especially if you’ve got a tiny outage window to deploy things to your live system, or if you do your production changes are done in the middle of the night while nobody else is around to fix the issue properly. I would say that these arguments rather miss the point. Firstly, if you have only a tiny outage window, hacking your live system should be the last thing you want to do, because this will invalidate all your other environments unless you similarly hack all of them as well. Secondly, the next time you do a deployment, you may reintroduce the original issue. Thirdly, if you’re doing your deployments in the middle of the night with nobody around to fix issues, then you’re not paying enough attention to the 7th principle of Continuous Delivery – Everybody has responsibility for the release process. Unless you can’t avoid it, I wouldn’t recommend doing releases when there’s the least amount of support available, it simply goes against common sense.

原创粉丝点击