Continuous delivery is a software practice which enables you to get tour software to customers in small, quick increments. It is a core part of lean and, to some extent, agile methodologies (rapid rather than continuous for agile). There are many benefits to this but its definitely not a silver bullet.
So what are the phases of a continuous delivery pipeline and how do we manage them?
Build automation
Most code needs to be built or packaged in some way, somehow we’ve even make ‘non-compile’ code such as javascript need complex and clever build requirements. To do this we use a continuous integration tool. At featureflow we use circleci and we think its great – there are other hosted options such as codeship – I would recommend if you can use hosted then do so. If your company insists on running internally then jenkins is the most popular old work horse. Their primary reason for being is to build your code when you check it into your source control.
Test Automation
This could warrant a post and book on its own. But the premise is this – use the above tools to run two suites of tests. Unit tests, they are compartmentalised by functional unit, self contained, completely repeatable and require no backend or external integration. THen there are integration tests – these typically combine a few services. If you were embracing a full CD pipeline it would be highly advisable to invest in a complete build up tear down environment – for example a docker compose managed set of services and databases can be used to run a suite of tests.
Deployment
Deployment is often done in at least a small pipeline, true mavericks may choose to fire straight into production (yes it has been known) but generally your going to deliver continuously to a dev and perhaps test environment then stage-gate into production, of course you need a method to rollback also.
How? There are a couple of approaches:
- Use a gitflow style process – this means you develop in a ‘develop’ branch – have that branch CI build and deploy straight into your test environment. You then pull request and merge your code once ready into a master branch and have that check-in initiate process to tag the code (in your code repository and fixing a build version in your code build), build and deployment to production. The benefit is a more controlled merge into master at the expense of delivery frequency but you run the risk of tough merges as developers inevitably shy away from the master branch over time. There are a number of different variations to this – often you may build a single deployale and push that through test to production. This depends how ‘continuous’ you are.
- Use a single master branch, build and deploy all the way through on each commit. This reduces branch and merge issues but opens you up to greater deployment risk due to its inherent all-in and straight through nature. How do you manage incomplete work at the end of the day?
In addition, continuous deployment may not match against the will and requirements of your product owners and marketing teams who may want to coorinate feature releases and upgrades with marketing campaigns or helpdesk preparation – or of course it may not fit to your customers who do not want to see continual and seemingly unplanned stream of changes.
So how do you manage that risk? How do you deliver frequently whilst still keeping control and giving the developer, the business, the marketing team and your customer control?
Well the next part is an essential part of the Continuous delivery pipeline that is often not included – most blogs you read will stop at the deployment part but this is wrong!
most blogs you read will stop at the deployment part but this is wrong
Runtime Management
The solution to managing the risk of throwing your features and code out in a continuous fashion is by adding runtime management. This gives you the best of both worlds. You can deliver continuously but be very specific about who you deliver continuously to, you can rollback instantly if a problem occurs or you can roll the code out with a new feature turned off completely.
Featureflow is the tool that can allow you to do that. You can set your rules up in dev and test as you develop your new feature, you can define new feature versions and decide before time to limit that version a subset of users, perhaps 20% of all users, perhaps just your ‘beta’ user – or perhaps just you. You can then check your code in and know that when it CD’s through to prod you are in full control.
If your a devloper you can toggle your feature as off completely and be more confident when you check your code in at the end of the day. If its not ready thats ok, you can still integrate early, but just leave it turned off.
How to..
1. Set up featureflow in your back and front end (if its a web or mobile facing app) – see http://docs.featureflow.io
2.Decide if you want control over your new feature or feature version as you define the requirements and discuss this in your standups
3. Discuss who your initial audience is – if this thing goes flying into production – who should see it?
4. Set your rules in your dev, test and production environment using featureflow’s intuitive UI – test it out in development.
5. Build and deploy, once the code is deployed you can use featureflow to roll out with control.
If the worst happens you know you can just toggle it off.
Hopefully this little blog demonstrated how featureflow can help you manage your continuous (or near continuous) delivery pipeline. Unlike other tools we fit right into your Pipeline across your development environments and into production.
If you have any questions do not hesitate to shoot us a message in the smily chat to the right there 🙂