Just recently I entered a discussion about getting application into the production environment. As we all know due to the silo’s and functional separation (currently in place at my job) it is challenging at a minimum.
Situation:
As the new features in the application near completion it must be accepted by the customer. for this purpose a PAT environment is available. So far it all looks nice. The problem is that the time between the releases is more than 4 months. In order to get the new version of the application running the following must be done:
- Upgrade the database server
- Add multiple tables to the database
- adjust or alter about 250 tables
- some environmental changes, upgrades of services used
This is a lot! It comes to no surprise that the deployment of the new application requires a lot of effort by the OPS team. And sure there are errors during the update of the database and table. Not to mention that the new services used face performance and functionality issues. Not even mentioned are the 150 RFC’s implemented.
Words from the field:
- The application is too complex.
- To much functionality is added.
- The application is buggy.
- Its to expensive to put in production.
**Management conclusion:
**Given the circumstances it seems wise to reduce the release moments. Currently there 3 times a year a release is executed. The complexity and costs associated exceed the expected profits.
To reduce the costs a new schedule is created. 2 times a year a new version of the application is published.
By performing the release just two times a year a cost reduction of at least 30% will be achieved. Furthermore the strain put on the OPS team is less. Instead of 3 times a year they have to insert effort just two times.
Why is this wrong:
- The “new” Devops and Agile movement say that when something is difficult we should do it first and try to automate that process.
- Users do not agree with the solution. The huge amount of changes in the application require them to plan and educate the staff for all new functionality.
- The strain of the OPS teams increases exponentially.
My suggestion in the meeting was why don’t we go for a daily deployment. Knowing that this is at the most extreme other side of the management view ( I wanted to contradict there opinions and start a fierce discussion).
The initial reaction was disbelief. How can doing something that takes so much effort be reduced by doing it on a daily basis? Is this not what the entire Devops and Agile movement is about? Things you do on a daily basis scream for automation. Things that are automated produce repeatable results. And more important when it goes wrong a rollback can be performed in a simple and controlled manner.
The OPS people, users and development teams are on my side. Lets start with a release cycle of lets say a monthly. With this we can get a feeling how it works and clear check points can be defined to see if the costs are reduced.
Management is not yet convinced, the jury is in the back room to discuss. In the mean while, for a new product we are starting with this process. We do have daily deployments on the test environment. PAT environment is starting now, lets see how often we can do a release there.
