If you're not familiar with Progressive Delivery, it's a new set of best practices that is gaining hold for delivering safely and frequently to production. Although it's not a completely new idea in the same way that continuous delivery originally was, it is a clear evolution of those ideas that brings something new to the table. By taking a step back and considering the corpus of knowledge and experience gained over the last 10 years, then applying a bit of systems thinking to how all these different practices interact with emerging technologies, it has set a new baseline for how software delivery can be done effectively.
We discuss our overall vision for Progressive Delivery on our CI/CD vision page, which also links to a few more resources if you're not up to speed with the concept in general.
In summary, though, continuous delivery gets you out of the mode of shipping one, big, risky deployment to production, and instead breaks that risk up into many tiny parts – each with a fraction of the risk. Progressive Delivery takes this a step further by enabling you to canary test code in production with a small portion of your user base, use feature flags to manage rollout pacing, tie everything together with tracing, and automate the further deployment or rollback of that code depending on how it performs.
How Review Apps can help enable Progressive Delivery
Let me begin by explaining what GitLab Review Apps are:
GitLab Review Apps are staging environments that are automatically created for every branch and/or merge request. They are a collaboration tool built into GitLab that helps take the hard work out of providing an environment to showcase or validate product changes. There are a lot of different ways to configure them, but the recommended way is to automatically create review app instances during your merge request pipelines. Doing this will ensure that any merge request that is being considered will have an application that developers can connect to to validate their changes.
With GitLab, we go a step beyond simply creating the review environment: we make it accessible.
Once configured, on your merge request page you'll now see a "view app" button that, as long as your route maps are configured correctly, will allow your users to jump right to the changed content. Review apps do work even without the route maps – in that case they will take you to the home page of your app – but with them they almost feel like magic.
Review apps are a powerful tool on their own for enabling quick iteration, but if we think about them in the context of Progressive Delivery, a whole new set of possibilities opens up.
Review apps for progressive validation
As mentioned above, a typical Progressive Delivery flow involves using targeted feature flags to validate changes as they flow to production environments. Review apps, if configured to point to production data/endpoints instead of ephemeral data, can serve as a merge request-based window into the changes that are being considered for release.
Some of this will of course depend on your code, your testing procedures, and environments. You may point review apps at production endpoints from the moment they are spun up, or perhaps only later in your merge request pipeline after some initial validation.
Since anyone can use these environments, you can point anyone with a stake in the success of the new feature to the review app, and they are able to see the live behavior, using their own real data, immediately in their own web browser. This is incredibly powerful for enabling rapid feedback and iteration. As a preview, we're also looking to improve this capability by adding an easy-to-use review interface for collecting feedback right into review apps directly.
Feature flags and tracing
We can take this idea even one more step further. Using per-environment feature flag behaviors, we can control the behavior of the review app environment in any way that the production environment can be controlled. This opens up the possibility of validating any combination.
Finally, since review apps are built and deployed from GitLab CI/CD, all the predefined CI/CD environment
variables are available to the deploy script. You could configure your application to use your
merge request ID (CI_MERGE_REQUEST_ID) as its unique ID for transaction tracing, tying transactions
in the system automatically to the appropriate GitLab merge request.
As you can see, there's a ton of potential for Progressive Delivery here
Review apps don't replace the role of feature flags in a Progressive Delivery pipeline, but they provide an incredible supplement that enables segmented validation in a completely new way. All in all, it's such an exciting time for continuous delivery – there's so much innovation happening on the process and technology fronts, and I'm certain we're only scratching the surface of where we're headed.
Review Apps is just one way GitLab CI/CD enables Progressive Delivery. Join us for our webcast Mastering continuous software development and learn how GitLab’s built-in CI/CD helps teams implement Progressive Delivery workflows, without the complicated integrations and plugin maintenance.
Watch the GitLab CI/CD webcast
If you have more ideas on how to use review apps even more effectively, or where you see the technology evolving next, please share in the comments.
Photo by Helloquence on Unsplash
