Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
Say you have a traditional dev > test > production process say on a monthly release cycle.
What are some of the steps you need to take and put into place to move towards a model of continuous delivery with frequent releases per day.
Please make one suggestion per response. I would be interested in using voting to indicate which steps the community feel are most important.
I'll kick this off to get us started....
Automated Testing
Having automated unit tests, integration tests and acceptance tests are vitally important if we're going to allow everything to flow straight through to production.
Even the best and most thorough manual testing process in the world would simply take too long if the application has any degree of complexity.
Setup version control (if not already) and define a branching model/strategy to follow.
The shorter your release cycles are, the more important branching will become and every developer must rely on certain branches to be in defined states.
I would suggest to have communication transparency between your
Development team <-> Testing team <-> Clients.
Cause most of the problems arise because of miscommunication.
Probably setup a sharepoint site to display the current status of development so everyone is aware of whats going on.
Update: Try also to plan a project status review meeting (every week possibly).
You need to automate the complete delivery cycle, so one feature you will need is
automatic deployment
For web applications, this often seems to be trivial, for desktop applications this depends a lot on how your production environment looks like and may be far from trivial.
Rollbacks
A fast and reliable rollback is going to be massively important if you are going to open the gates to continuous delivery.
In the case of issues, you want to be able to switch back to the previous known version of the software at the first sign of problems.
Closely related to this would be good monitoring tools that quickly alert you to odd states or errors that are occuring in your application.
I find that the quickest and biggest improvement to get folks moving down the path is to set up a build machine and integrate it to kick off builds when code is checked in to version control. Even if the boss doesn't let us move any further down the CI/CD path, having builds ready all the time saves on stress and eliminates the "only Bob has the right stuff on his machine to make the build and he went home hours ago" stress.
