chris clarke
software development that works…or something
Continuous Deployment As A Practice
May 26, 2007 on 12:51 pm | In Continuous Integration |A lot of people do Continuous Integration these days (even if that just means source control and CruiseControl). But very few teams seem to do any form of Continuous Deployment. The point of Continuous Integration is to detect integration problems as quickly as possible and to reduce the risks involved in a deferred integration. A deferred integration is something that will delay the release and may take an unknown amount of time and involve an unknown amount of problems. As Martin Fowler says in his article:
“you are putting yourself into a complete blind spot right at one of tensest parts of a project”
So why is deployment any different? If your deployment process involves things that have not been done continuously every day, such as packaging files, copying them to servers, installing, configuring & starting processes, then you are doing deferred deployment. A deferred deployment is something that will delay the release and may take an unknown amount of time and involve an unknown amount of problems.
It may not be as easy to do Continuous Deployment - so keep it simple at first - grab your build artifacts from your Continuous Integration server, deploy them, automate the rest of your deployment process - then run some simple Deployment Tests:
- Is it up?
- Does it work?
Worry about adding more complicated things such as testing failover, load balancing etc. later. Just get some simple, automated deployment test coverage. I’ve seen & heard a lot of painful release processes, ones that take to 5 in the morning, ones that take 8 hours on the weekend, ones that involve a degree of ‘trial and error’ - don’t ignore your deployment problems - make them visible and try to fix them, just like you would with a slow build or a failing CruiseControl build.
No Comments yet »
RSS feed for comments on this post. TrackBack URI
Leave a comment
Continuous Deployment As A Practice
May 26, 2007 on 12:51 pm | In Continuous Integration |A lot of people do Continuous Integration these days (even if that just means source control and CruiseControl). But very few teams seem to do any form of Continuous Deployment. The point of Continuous Integration is to detect integration problems as quickly as possible and to reduce the risks involved in a deferred integration. A deferred integration is something that will delay the release and may take an unknown amount of time and involve an unknown amount of problems. As Martin Fowler says in his article:
“you are putting yourself into a complete blind spot right at one of tensest parts of a project”
So why is deployment any different? If your deployment process involves things that have not been done continuously every day, such as packaging files, copying them to servers, installing, configuring & starting processes, then you are doing deferred deployment. A deferred deployment is something that will delay the release and may take an unknown amount of time and involve an unknown amount of problems.
It may not be as easy to do Continuous Deployment - so keep it simple at first - grab your build artifacts from your Continuous Integration server, deploy them, automate the rest of your deployment process - then run some simple Deployment Tests:
- Is it up?
- Does it work?
Worry about adding more complicated things such as testing failover, load balancing etc. later. Just get some simple, automated deployment test coverage. I’ve seen & heard a lot of painful release processes, ones that take to 5 in the morning, ones that take 8 hours on the weekend, ones that involve a degree of ‘trial and error’ - don’t ignore your deployment problems - make them visible and try to fix them, just like you would with a slow build or a failing CruiseControl build.
No Comments yet »
RSS feed for comments on this post. TrackBack URI
Leave a comment
Powered by Cheese.
RSS Entries Feed.
RSS Comments Feed
^Top^