Practical Platform Engineering in 5 Lunches is a series of blog posts that takes you through the process of building a hands-on Internal Developer Platform (IDP) using Octopus Deploy.
This is part 4 of the series. In the previous post, you pushed changes to a shared process template in Platform Hub and saw how those changes were automatically consumed by the project that used the template.
In this post, you’ll build a project that supports a shared responsibility model, with multiple teams owning different stages of a deployment.
Prerequisites
Sign up for a free trial of Octopus Cloud at https://octopus.com/start. The cloud-hosted version of Octopus is the easiest way to get started, as it doesn’t require any additional configuration to work with the Octopus AI Assistant.
Then install the Octopus AI Assistant Chrome extension from the Chrome Web Store.
Updating the project structure
Open the process for the K8s Web App project. You already have the Platform PreDeploy Hook step template as the first step. This effectively means the platform team owns the start of the deployment process.
:::div{.hint} You must publish process templates before they can be used in a project. See the second post for an example of publishing process templates. :::
Add the Security PreDeploy Hook process template next. This gives the security team the opportunity to implement any security checks or processes that must be run before the deployment can proceed.
Add the Security PostDeploy Hook and Platform PostDeploy Hook process templates as the final two steps. This allows the security and platform teams to implement any checks or processes that must run after the deployment completes.
All process template steps default to the name Run a Process Template, but must have a unique name to save the process. Rename each of the process template steps under the Settings tab and define a new name in the Name field:
You must also configure the worker pool parameter for each of the process templates.
With these steps in place, you have modelled your project to support the cross-cutting concerns of both the platform and security teams. This embraces Conway’s law, which posits that organizations design systems that mirror their own communication structure. Conway’s law is sometimes seen as an unintended consequence arising in organizations, but regardless, it is a common pattern that must be supported by platform teams.
By wrapping deployment processes in shared templates like an onion, each team can own and maintain their part of the process. Combine this approach with the Git based workflows for managing changes to process templates, and using SemVer for quantifying the impact of changes to those templates, and you have a powerful combination of features that allow you to manage process templates at scale:
The onion model is just one example of how process templates can be used. You are, of course, free to create process templates defining more general deployment processes that don’t necessarily fit the pre/post-hook model. The key point is that process templates provide a powerful mechanism for sharing and maintaining architectural decisions, and Platform Hub provides strong opinions to support platform teams in managing those architectural decisions at scale.
What just happened?
At the end of this post, you have:
- Updated the project structure to support a shared responsibility model, with multiple teams owning different stages of the deployment process.
What’s next?
You are 80% done with the series. In the next and final post, you’ll explore policies, which provide guardrails for projects to ensure they are compliant with organizational standards.
