Maximizing Dynamic Environments for Speed
Using shared, persistent test environments creates an overly complex and bottlenecked workflow that represents an inherently flawed process in a software development lifecycle
This is the dynamic environment playbook that we created internally at Uffizzi and that we use to average a release every working day. Uffizzi dynamic environments fill the gap between your local development and production to expedite code reviews, testing, merge times, and release velocity. It's like moving at "hot fix" speed but with the appropriate level of testing baked into your process.
Dynamic environments can be used in many capacities but their main benefit is setting your team up for blazing fast release cycles. Uffizzi enables you to make a change, test the change, release the change or in marketing speak it’s Develop - Preview - Release.
With dynamic environments each feature branch can be iterated upon in its own isolated, independent track with no impacts to all the other changes simultaneously being developed.
If we have a major release that relies on several feature branches that create an epic we will merge all the feature branches into a combined topic branch and then open a PR from that branch to our develop branch. The Uffizzi workflow recognizes the trigger and creates an dynamic environment so that now the epic can be tested as an entire release.
As your team grows and your automated testing matures you’ll be set up to maximize the advantages of parallel dynamic environments, whereas teams using persistent environments are inherently set-up for diminishing returns. When quality and stability start to outweigh speed in importance to your business goals you’ll be ready. Uffizzi acts as a quality gate by preventing buggy code from ever being committed to a downstream branch.
Over time we recommend increasing the sophistication of your testing process to a risk-based method which you can easily add on top of your dynamic environment capability. We use and recommend a risk-based tagging system to indicate an appropriate test track:
1. Fast Track = Dev Test
2. Routine Track = QA Test
3. Deliberate Track = PM Test
Any Developer on the team can build, test, and ship their own feature tagged as “Dev Test” - this is how you should operate with any early-stage project but as your project gains stability this type of testing method sets you up for a hybrid approach that optimizes for speed and quality.
Once you’ve adopted dynamic environments into your workflow you’ll never look back at the old way of testing and releasing.
Like this article?
Subscribe to our LinkedIn Newsletter to receive more educational content.
