Here at featureflow we enjoy being able to run a fully automated deployment pipeline. This allows us to perform small incremental releases quickly (every 5 minutes if required) of any of our components and gives us a host of great benefits, the sort of which I’m sure you have all read about in every ‘Continuous deployment’ blog out there.
This is no silver bullet however, it’s hard work – frequent deployments can create disruption (of the bad kind), instability, risk and if your running microservices synchronisation issues – so how to we manage it?
We found its about enabling ourselves at the core. So we start with a great devops capability. We use GIT, CircleCI, AWS, Docker Rightscale and Rancher in our core stack. This stack is application agnostic, docker allows us to generify the deployment of any service we like whether its a java microservice, nginx or other application. Rightscale allows us to spin up the entire environment with monitoring and Rancher is a fantastic tool to schedule and manage our services across this envirnoment in a Highly available manor- we can very easily tell rancher to spin up a new set of containers, switch over only after they have started (instantly using HAProxy under the hood) and then only if the new release passes our QA to we approve it, otherwise they are simply rolled back out (shut down and docker containers removed) and HAProxy is returned to the old severs. That helps us manage an entire deployment but still leaves us open to failures when the new continer is switched over – to reduce risk further, and to control the rollout of individual features we use ourselves – we use featureflow to manage featureflow.
Woahhh there – some kind of inception thing must be happening there! And yes it is. Whenever we develop a new feature we will link it to a feature in featureflow and leave it turned off in production. So when we release we check that nothing has happened. That makes us happy. If nothing as happened and no-one has noticed, that is the best kind of release!
Initially we may test large features against our dedicated ‘pvt_user’ role – we do that using our rules mechanism – we turn on the feature only for the ‘pvt_user’ role. Once were happy with our testing we turn it on for our trusted ‘alpha_role’ group – this isn’t a group of beer chugging frat boys but our bleeding edge users that are keen to try the latest and greatest. We can turn on exactly when required (usually once we have sent out our release notification email) and we can leave it in the alpha channel for a week or so. We follow the same process with our beta users.
When you log into featureflow you have a particular set of user roles – you may be a standard user, an organisation admin, an ‘alpha’ user or a ‘beta’ user. We pass that information to our featureflow context and this allows us to target precisely.
Hopefully you can see how the combination of great devops and sophisticated application-level management allows us to manage both the physical deployment and the subsequent feature rollout within our application. There are a million-and-one other use cases for featureflow when managing your releases such as