官术网_书友最值得收藏!

Continuous Deployment

The final stage of automating your software development process is Continuous Deployment. When practicing Continuous Deployment, every check into your source control is deployed to a production (like) environment on a successful build. The rationale behind this is that you are going to deploy the software to production sooner or later anyway. The sooner you do this, the better the chance you'll be able to fix bugs faster. It's easier to remember what you did yesterday that might have caused the bug than it is to remember what you did two months ago that might have caused the bug. Imagine checking some code into source control and get error messages from your production environment five minutes later. You'll be able to find and fix the bug immediately and, five minutes later, the production software is up and running without bugs again. Unfortunately, most managers and software owners I know get pretty nervous at the thought of automated deployment, let alone automated deployment on every check in.

Again, as with Continuous Delivery, Continuous Deployment is not always possible. All the issues with Continuous Delivery still apply, except now when a DBA doesn't give you access to the database, Continuous Deployment is pretty much out of the question. After all, you can't automatically deploy software multiple times a day while your database is only updated when some DBA has time. Currently, I'm working on a website for a customer who in turn has a customer who needs three days' notice before any changes to the website can be made. It's a contractual obligation and whether it makes sense or not, it is what it is. So in that particular case, Continuous Deployment is obviously a no-go. Still, we use this technique on our own test environment and automate as much as possible while still giving three days, notice.

The difference between Continuous Integration, Continuous Delivery, and Continuous Deployment may still be a bit vague. Consider the following image (I apologize for my poor MS Paint skills) which indicates where the three types start and stop:

Does all of this mean we have no more manual tasks? Not at all. For example, the only way that you're going to know if what you build is actually what the customer wanted is by having the customer see it and, ideally, use it. So the customer should validate any changes manually. Even if it's just a bug fix, your customer probably wants to see that it's fixed with his own eyes before you can release to production. Likewise, exploratory testing is a typical manual task. Other tasks, such as making changes to your firewall, (web) server, or database may (or even must) be done manually, although preferably not.
主站蜘蛛池模板: 房产| 三亚市| 绥宁县| 宾川县| 成都市| 嘉禾县| 内黄县| 牡丹江市| 奉贤区| 无极县| 梁河县| 丰县| 保定市| 筠连县| 绥宁县| 玛纳斯县| 内黄县| 宜兰县| 冀州市| 永登县| 龙泉市| 旬阳县| 博客| 枣庄市| 仁怀市| 黑水县| 马边| 绍兴市| 荆门市| 都江堰市| 静乐县| 利辛县| 桐乡市| 华蓥市| 双峰县| 康定县| 北海市| 沙坪坝区| 甘孜| 宜春市| 南阳市|