- What is AI networking? How it automates your infrastructure (but faces challenges)
- I traveled with a solar panel that's lighter than a MacBook, and it's my new backpack essential (and now get 23% off for Black Friday)
- Windows 11 24H2 hit by a brand new bug, but there's a workaround
- This Samsung OLED spoiled every other TV for me, and it's $1,400 off for Black Friday
- How to Protect Your Social Media Passwords with Multi-factor Verification | McAfee Blog
Continuous Previews (CP): Don’t Merge Until You Preview – Docker Blog
Docker’s Peter McKee sits down with Uffizzi Co-founders Grayson Adkins – who serves as Head of Product – and Josh Thurman – who serves as Head of Developer Relations – for a Q&A on the CP method.
Check out the live stream from August 26th for
Docker Build: Enabling Full-Stack Continuous Previews with Uffizzi
(The below transcript has been edited for clarity and format)
Peter McKee: It’s great having you guys back on the Live Show. I love the idea of Continuous Previews, tell me what brought you guys to the concept?
Grayson Adkins: The kernel of the idea – no pun intended – came from our own challenges in trying to develop our product faster. We continued to observe two problems that were hindering forward progress.
On the development side we were too often merging broken features – and then we would have all this commingled code and finding where the bug was introduced and then fixing it was really hindering progress. The returned tickets were always holding us back – the classic two steps forward, one step back.
On the product side I do all our design work and I kept finding that the design/requirements would need to be modified as I saw the product come to life. And when I would ask “Can I see it yet?” there was no easy solution to that. So for me to see a new feature and provide feedback I would have to wait until the branch was merged and deployed to our QA environment. Then the feedback process would start and, as tickets are returned, they’d go back through this big loop of “In Development”, then merge and deploy, then I can check it again. There was too big of a gap between Development and Product.
At the time Uffizzi’s product direction was moving towards making it easy for Developers to deploy their apps to the cloud and once we realized we could fix the “dirty code in main” and “can I see it yet” problems with the same process I realized we could repurpose what we had built to be a Preview Engine for full-stack and microservices applications – something where you could “Continuously Preview” what’s in your feature pipeline.
Josh Thurman: There’s two other big picture elements that brought this into focus for us. Everyone has seen the success of the Frontend Preview tools by static site platforms like Netlify and Vercel. Their success taught us that making it easy to Preview was extremely valuable for teams, but no one had really formalized the concept and the supporting technology for more complex applications. So we realized that the Preview concept shouldn’t just apply to frontends, it should apply to everything that we build.
The other major factor was observing how the complexity of microservices architectures and remote work were making it harder to collaborate – particularly as teams and app ecosystems grow in size and complexity. So the Continuous Previews concept is really about removing barriers to collaborating early and often – it’s about taking away all the barriers between the developer coding the feature and the team member who is reviewing or approving it.
At a high level, Continuous Previews equals continuous collaboration – so you have a process and technology that is facilitating a collaborative culture and that’s really when you start to see major improvements in team velocity, cycle times, lead times, and code stability.
Peter McKee: I’ve read the CP Manifesto ( www.cpmanifesto.org / https://github.com/UffizziCloud/Continuous_Previews_Manifesto ) that outlines the principles of CP, what inspired you to write and publish that?
Josh Thurman: It was clear to us that CP is so much bigger than any tool or service, and we also recognize that it’s easy to confuse tools or products with concepts. So we took a cue from the Agile Manifesto and decided that the CP concept and its underlying principles need to be out there for everyone to benefit from and to understand the “Why?”.
Grayson Adkins: The Agile Manifesto is the governing document for how to build software as a team, and we see CP as a best practice that’s nested within the Agile umbrella.
Peter McKee: Reading the CP manifesto and talking to you guys a few times about it I have a good sense of what CP is at a strategic level but tell me about the tactical level, how does it impact teams on a day-to-day basis?
Grayson Adkins: Most teams follow similar Development workflows that align with the Agile Loop of Design, Develop, Integrate, Test, and Deliver. When you’re following this process a Developer picks up a ticket, checks out a branch and starts developing. Once they think they have met the requirements, they then indicate that their ticket is ready to be merged by opening a PR.
Take this process and multiply it by the number of developers working on different features and you end up with X amount of features that are ready to be merged. At some interval you execute CI (Continuous Integration) and now you have a batch of new features in your QA environment where for the first time in this process they are ready to be reviewed by someone other than the Developer who coded the feature.
The problem with this process is that you are bringing QA in way too late in the game. Once a feature has been merged and deployed it’s 10x harder to find and fix a bug as opposed to catching the issue(s) early and addressing it at the feature branch level where, again, it’s relatively easy to find and fix.
When a developer pushes new code using the CP method it can be QA’d without merging – and also without the Developer having to context switch out of their Git workflow. The Preview has eliminated the barrier to the collaboration, and your iterative process of Develop – Preview, Develop – Preview is happening faster, and it’s also happening earlier in the development process.
In a more literal sense you are bringing QA into the development process where traditionally it has served as an add-on function.
Josh Thurman: I’m glad you said teams generically as opposed to saying Development Team or Product Team. Even though we see most organizations task-organize into Dev Team and Product Team, I think the construct can be a hindrance to collaboration. CP is a process for “The Team” meaning everyone who contributes to the success of a product.
Peter McKee: You guys have mentioned barriers to collaboration – what exactly are those barriers that teams face now?
Josh Thurman: Good question. The cleanest way to have your application readily accessible to everyone on your team for testing is to have it deployed to the cloud and reachable via a secure URL endpoint. I should emphasize here that the endpoint could be to test your full-stack application or any of its individual components like an API or a front end element as examples.
To deploy a version of your application you need a hosting environment – and setting that up – particularly for a complex or microservices-based application – is no easy task. Most teams have persistent environments like Test, QA, Staging, and Production that are maintained by your DevOps and Ops team members. To set up a new environment just to test one feature branch is a significant barrier.
The CP method calls for on-demand hosting environments that have a purpose-driven lifecycle. They are stood up to Preview and Test a feature branch and then they are taken down after that feature is merged. This is where technology comes in and this is what Uffizzi does so well. Uffizzi provides teams with an off-the-shelf solution that completely automates on-demand hosting environments with policy-based triggers that facilitate the preview. You can have as many test environments as you need, when you need them, for the amount of time you need them.
And I’ll just add that with this method you also remove your single point of failure when you have a persistent QA or Test environment go down and have to spend most of a day fixing that.
Grayson Adkins: The other barrier is DevOps expertise. Just as one example – it’s a significant jump in complexity to go from a 20+ line Docker Compose file to a 1000+ line YAML file. DevOps expertise is often it’s own bottleneck within an organization, and if you can reduce the demands on them with an automated solution that’s a big win.
To follow best DevOps practices we’ve centered the product around infrastructure-as-code through a uffizzi-compose.yml that is syntactically the same as docker-compose.yml (based on version 3.9) but with some additional inputs.
But we also have a GUI and the concept of Templates that are meant to increase accessibility – the CP concept is something that can benefit teams of all sizes and skill levels, and we want to act as a DevOps force multiplier in those cases.
Peter McKee: Speaking of barriers, what do you guys see as the biggest hurdle to teams adopting a CP methodology?
Josh Thurman: For a method to take off it needs to be paired with a technology that is easy enough to use that it really starts to proliferate. Again to reference what Netlify and Vercel have done, they made it simple enough that Frontend Previews have really taken off in the last few years.
Of course this is what we are trying to do with Uffizzi in the context of full-stack and microservices applications. We are offering a very specific tool that makes it easy to implement CP by abstracting away the complexity of managing hosting environments and deployments.
Grayson Adkins: I think the other issue is overcoming the inertia of “good enough”—everyone is getting the job done now, so why do they need a new way of doing business?
This is the same hurdle with every new process and technology. Before Agile, Waterfall was good enough. Before container orchestration, VMs (virtual machines) were good enough. So I think we’ll go through an early adopter period, and you eventually get to a point where the competitive advantage is such that it requires organizations to implement CP or they risk getting left behind.
Peter: As we wrap up what we can look forward to from Uffizzi – what’s on the Road Map?
Grayson Adkins: We’ve got some exciting new features rolling out. In the near term we are expanding our integrations both with image registries and collaboration software. We’re currently rolling out integrations with image registries at all the major cloud providers – AWS, Azure, and GCP. Then over the next few months we’ll add Gitlab and Bitbucket for repos and then Slack, Jira, Microsoft Teams, and Asana on the collaboration side.
Peter McKee: Well this has been fantastic, I really appreciate your time and your thought leadership. I can see how this is a game-changer for how organizations build and test. I look forward to seeing how CP and Uffizzi continue to benefit the Dev Community.
If you have any Docker-related questions, please feel free to reach out on Twitter to @pmckee and join us in our community slack.
If you have any Uffizzi-related questions, please feel free to reach out on Twitter to @uffizzi_ and join us in our uffizzi users community slack – Josh Thurman (@JoshThurman19) or Grayson Adkins (@GraysonAdkins).
You can view the CP manifesto here- www.cpmanifesto.org
And the Open Source Repos here- UffizziCloud/Continuous_Previews_Manifesto: Source for: https://cpmanifesto.org
