Getting code done for a feature from developer's machine to production in less time is a quality of efficient tech/engineering teams. Automated deployment with tools like capistrano or fabric make deployment an easy task than a dreaded operation where you miss one step and then screw up on production.
These days Docker and Kubernetes make deploying a breeze. This post will highlight things to consider when you deploy a new major feature that involves some big code and database changes.
What is a Major Feature
How to differentiate between a regular and major feature deployment? For example, if you deploy a customer wallet subsystem in an e-commerce website or you deploy a multi-tenancy feature to a single tenant application it should be considered a major feature being rolled out.
Regular features don't need a roll-out plan or lots of thinking beforehand, they can be deployed with running your regular deployment routine and its okay. Major feature stands to be a type of sub-project amid the regular features and bugs. Deploying a significant feature is a shared responsibility of the development, sys admin/devops, and the product team.
TLDR;
Before going live/production with a new major feature, always tests rigorously on staging. Do a database backup and deploy small with backward compatibility. Always have a rollback plan and keep features under a feature flag.
Things to consider
So, what are the things you need to consider when you want to deploy the new major feature that the team has finished development with and wants to go on production with it?
Below are the things that you should make a checklist of before doing a major deployment that involves big code changes and some database schema changes with migrations:
1. Rigorous testing on staging
This is a no-brainer, you must test the new feature rigorously on the staging environment and be sure that you covered the different use-cases. I would even suggest having a google sheet which lists the possible cases and tests it.
If you have Quality Assurance (QA) department you could surely take their help on the matter.
Developer level testing is also very vital and it costs a lot lesser to find a bug on staging and fix it than to go live and have a rollback.
You may need to rollback because of the significant bug being discovered on production. That is a situation you don't want to be in. The question would be if it is release ready or if the testing takes too long it can delay the release.
2. Always take a database backup
Taking a backup is the most essential thing you will need to do before making any changes to the production database. It is one of the small things that if you forget you could invite a disaster.
Problems snowball into bigger ones when you don't get the basics right.
So beware and always take a database backup before running those migrations/alter queries. Also be alert that the deployment script does not run the migration automatically. This can make the major feature deployment process painful, thereby always be prepared for the difficult situation.
3. Small multiple deployments, preserve backward compatibility
When you have to deploy a major feature to production, it will be a good idea to have the needed database changes on production which is fully backward compatible.
You can get the alter tables and new columns done on the production database. This helps you split the major feature into smaller parts and deploy them step by step.
This gives the flexibility and confidence to the team to go on to production with the new feature. This can be an enabler of zero downtime deployment if you can play your cards right.
4. Don't forget the rollback plan
If you plan to do one major deployment to release the major feature, have a roll-out plan. It details how to execute the deployment with proper steps which elaborates the roll-out strategy.
Even if you think that the roll-out/deployment is going to be successful always have a rollback plan.
List out the things you will need to rollback to the current working version of the application in case things don't turn out as planned and you need to revert. If you have minor issues which can be fixed fast you will not need to rollback, still if there is a significant issue a rollback will be the only way out.
5. Features based on a condition
Last but not least, if you are deploying a major feature giving early access to your company employees (or a group within the company) is always a perfect idea.
Like the feature could be tested on production by the product team.
You are now asking how? It is simple just restrict the feature code to be executed when the user is logged in with @yourcompnay.com email address. Once I remember we did it for rolling out a payment method that it would show up only if you use one specific email address. So the major feature can be deployed to production and still have a filtered access. After the concerned team gives a green light you just remove the condition to access the feature and make it available to all customers/users.
Conclusion
As far as applicable aim for zero downtime deployment and run your database migration script on production when the traffic is lowest. Even if you must have downtime, make sure to look into ways of making it as less as possible beforehand so that the system can be under scheduled maintenance for the least amount of time. Happy Deploying.
Originally published at Geshan.com.np, you can read more things there.
Top comments (2)
For the condition, make sure that it is something that doesn't require a deploy. At my job we use feature toggles that require a build, and I've lost count of how many times I've forgotten to enable it before deploying to a test server.
You can use launchdarkly.com for feature toggle as a service. Good thought @robert .