Freedom to Release

Are you ready to deploy your new feature or service into production and require some hardware to run your code? In other organizations I’ve worked at, you are at the beginning of a multi-month process.

1. Obtain Capex justification
2. Pass a quarterly budget appraisal
3. Pass the architectural committee review
4. Pass the hardware requirement justification process
5. Prepare a capacity planning forecast document
6. Obtain senior management signoff
7. Obtain business sponsor approval

At Flow, we have none of this. We run homogeneous microservices deployed straight to production. All developers are free to create a new service that meets their team's requirements, and are trusted to deploy to our cloud environment with no red tape or management approval. You are the engineer with the best knowledge of what is required to deliver business value! 

Ok, you’ve deployed your new service to production at another organization and it is time for new features or a bug fix release.

Do you need to?

1. Coordinate with the security team
2. Coordinate with the infrastructure team
3. Coordinate with the deployment team
4. Coordinate with the support team
5. Coordinate with the outsourced offshore release team
6. Complete a 143 field release request form
7. Attend the multi-department weekly release meeting
8. Schedule the datacenter forklifts required to move the server racks (yes, I’ve really had to do this) 
9. Deploy to dev ⇒ test ⇒ uat1 ⇒ uat2 ⇒ staging ⇒ pre-prod ⇒ production
10. Package into a quarterly, or larger, big bang release
11. Avoid demarcation disputes
12. Obtain QA signoff
13. Obtain Business sponsor signoff
14. Obtain Senior management signoff
15. Obtain signoff from every other team that communicates with your software
16. Obtain CIO signoff if your release needs to happen within the next 24 hours
17. Spend all weekend performing a stop-the-world release

Again, at Flow we have none of these requirements. We build our software as small incremental features which are deployed straight to production once the CI build is green and the merge button pressed.

Yes, sometimes something goes wrong: a release may cause a regression, introduce a bug, or in the worst case, an outage. At Flow, we are willing to accept these risks for the advantages of reducing time-to-market. 

Engineers are responsible for increasing their unit test coverage and only merging when green. When not sure about a change we can easily ask a colleague for a code review. If there is a failure, we embrace a blameless post mortem culture to identify the root cause and reduce the risk for next time.