Software release processes in an Cloud-based environment.
One of the questions I get asked most often by prospective customers is how they will be able to release new versions of their custom software to their websites under AppLogic or VMWare. Generally, ENKI does not allow customers to have root access to their own production websites if they place responsibility for keeping them up onto us, so that we can keep track of any changes that are made in order to provide maximum uptime and minimize flailing about to find out who changed what. Database access is provided, however. I'll describe our release processes in this context. If you have your own Cloud installation, you'll want to partition responsibility in a similar way between your developers and your operations staff in order to have reliable and short release windows.
Our Operations as a Service (OaaS) basic release processes are described below, but bear in mind that the actual process has to be flexibly defined depending on the structure and design of your application, and may require a custom process.
No Database Migration Needed
- We create a copy of the production site to make a test environment.
- The customer copies the release candidate code via scp/ssh into the test environment and tests it.
- When the testing is complete, the customer stops the production environment and notifies us that the test environment is ready to be released.
- We rsync any changes to the live site data from the production environment into the test environment where appropriate.
- We alter the IP addresses to make the test environment be the new production environment and restart it to complete the release.
Database Migration Needed
- We create a copy of the production site to make a test environment.
- The customer copies the release candidate code via scp/ssh into the test environment, migrates the data, and tests the release candidate.
- The customer creates a patch process document describing the necessary steps to update the code and run the migration, and provides an SCP server for ENKI to retrieve the updated code - usually in tarball form - from (which may just be the test environment.)
- When the testing is complete and the release is determined to be ready, the customer notifies ENKI, which stops the production environment and restarts it on a temporary IP address. A site-down server is started to notify users.
- ENKI deploys the code updates and runs the migration according to the patch process document (or, alternatively, the customer runs the migration).
- Customer tests the production site and notifies ENKI when they are satisfied. ENKI alters the IP addresses of the production environment to bring it live and restarts it to complete the release.
Minor patch
Customer notifies ENKI and provides an scp server with the patch on it, together with patching instructions. We stop the live site, perform the patch and restart the live site.
Minimizing Down Time
Clearly there are are quite a few variations that can be made to these processes, depending on the customer requirements. For example, if the live site cannot be allowed to go down for more than an absolute minimum, the migration-based process could be modified to include keeping transaction logs on the live site while the patching and migration took place, followed by a database update from the logs while the live site was down. This of course depends on selecting a database that can reliably work with transaction logs.
We're well aware that many of our customers are in the volatile social networking, SaaS, or mobile application space where downtime can cause a permanent loss of customers due to impatience or bad publicity, so it makes sense to create a custom release process that minimizes the risk. One of the great benefits of AppLogic or VMWare when combined with on-demand or utility computing service is that you can work out all the kinks in your release process on an instantly-provisioned copy of your live site while customers are still using the previous software version.
TrackBack URI for this entry
