Defining A Pipeline for Metadata Deployments — Part 2

In last week’s article we outlined the importance of Defining a Pipeline for Your Metadata. This enables a team to have a set process for making deployments. It gives each step of the process a role and responsibility. Some changes will inevitably move from start to finish quicker than others, have a smaller scope of work, or be valued more by the business than others. For these reasons it is important to have flexibility in your release process.

Having flexibility with a release process sets a team up for success and enables them to become Agile. Agile and being flexible are not the same thing but, by definition, Agile encourages flexible response to change. The Agile Methodology has 12 Principles. Of those 12 Principles, 3 stand out as they can be used to keep a release process flexible.

Embrace Change

The release process’s goal is to push changes to production and that each stage adds value to the pipeline. Within these stages you need the ability to add or change the work being deployed. For a team to have flexibility within their release process they need to embrace change.

Embracing change is important to the health of a team and should be incorporated into a release process. Every change doesn’t necessarily get updated or added in the lower environment only. An edit or logic change may not be found until later in the pipeline. That is why a team that embraces change should make sure their pipeline does as well.

Business and Developers Together

A pipeline needs to support changes and features that support what’s in the best interest of the business. This means the business needs to value the work that a developer or admin is doing. Teams support a business when they feel valued and that the work is benefiting the organization.

Having this alignment means a user story needs to reflect where the feature, enhancement, or bug truly is. This allows the business to gain insight into the work without having to pester the team or user completing the work. Having this transparency and trust allows for collaboration from both sides. This means constantly updating the user story’s status, comments, & other relevant information so it is reflective of the work.

Not only is updating the user story important but understanding the features and needed work will change. Some work may be put on hold as needs change. Developers & Admins need to support what is best for the business and be flexible in the work they’re needed for. The business will need to have clear messaging of why something needs to be worked on especially when it is over something else.

Regular Reflection and Adjustment

Flexibility in a process allows a team to make adjustments to the process itself. An update to the view of a record doesn’t need to follow the same pipeline as a new feature release. Some work will go through a pipeline with more stages than others. Being able to adjust the pipeline, to the flow that fits the deployment best, will ensure quicker deployments to production without losing quality.

Not only adjusting the pipeline but adjusting the work done in each stage. Your QA team may have to reprioritize the testing they’re completing as a new feature is taking priority. Your Developers & Admins will need to jump into a different project than their currently working if QA finds plenty of errors that need fixed before a deployment to production.

Regular meetings to conduct reviews on a release should be as important as those spent planning one. Being able to look back at the flow of metadata through a pipeline will reveal certain bottlenecks and what added value to that release. Don’t save recap meetings for when a release goes poorly.

A DevOps pipeline should be a focus for every release team. Outlining one shouldn’t be where it ends. Creating rules in that process that favor flexibility ensures the team and business will benefit.