Code workflows
• Mark Eschbach
Ever use Git Flow? Ever had to deal with the complex development flow which fallows? How many feature branches does it take?
We’re developers. Code is our domain. Sometimes things don’t work right, sometimes they are awesome. Modern source code management systems are revision control systems at their hearts. The code really provides one value: artifacts to be shipped into production.
After working with multiple organizations on their continious development pipelines Gitflow drives me batty. I’ll be honest: I rebuked it early. Too many directions things can flow, too many feature branches. For most systems we don’t have the luxury of deploying new infrastructure to test each feature branch. Sure, if a feature is going to to take months to land in productoin it would be fine to justify the 3+ hours to setup a new environment. To correct a small bug though? Dodesn’t really make sense.
Most organizations are setup with two pre-production test environments and one production environment. One environment is intended to be the code integration environment and a developer data sandbox. The environment is there to be messed with. Data may be lost with a bit of noise. However is something goes wrong then we just rebuild the data store and move on. This environment is production like with possibly exceptions printing enabled within the environment.
Once a the developers are brave enough the software is promoted into a testing environment. Data within this environment is considered important as it would take a while to reproduce. This environment usually contians the testing permutations to ensure the software will function as designed in production. The torture environment within the release set. Automated UI tests should verify the code updates. Many organizations deviate here exactly who is responsible for pulling the lever but once a sufficient level of confidence has been reached the software is promoted into production.
Production data is generally considered sacred. Production runtime artifacts are generally not held to the same level of importance as our build system can hopefully reproduce a build from a specific version. Our users rely on to accomplish their gaols, the code we hope is relatively bug free and stable.
Is this the process for every software system? Not nesseciarly. But it’s the prgramtic best practices for web systems. Here deployments are relatively cheap, usually invovling cycling a few things out in a couple of minutes. For some real time data processing systems they might have additional performance tests they run to verify throughput. Others who are concerned about exposing a product of the software might collapse the environments as they are less concerned about the software and more about the work product of that software.
For many systems there is an addtiional environment: the hotfix environment. This environment is a similar classification as the release candidate: a verification environemtn. A hot fix environment allows one to quickly build a patch against a production system and verify it fixes those problems before a release.