Defining A Pipeline for Metadata Deployments

Sandra’s Salesforce team is missing release day deadlines. Her company’s size and appetite for frequent org changes has grown. Sandra has always been a confident leader and made efforts to meet this demand. She tried creating sandboxes for each feature, and then one for each individual. These changes helped but also made other parts of managing her releases more difficult.

For instance, having more sandboxes made the work more difficult for their QA team, as sharing access to these sandboxes was difficult to organize. Furthermore, when they tried to QA work in Production, it didn’t take long for leadership to notice the poor metadata being deployed to their org. Being in separate sandboxes also created duplicate work among her team. Sometimes a few individuals would work on the same metadata and whoever deployed last would overwrite the other.

These problems, among others, were creating an unstable environment and repeated failures that drove down productivity and team morale. The good news is her team can start fixing their problems by defining a release pipeline for their metadata.

Why?

Defining a pipeline for deploying metadata is important. It allows for scalability as the amount of needed work changes. The world’s most recognizable brands deploy to Production more per day than Sandra’s team did in a quarter. Keeping up with internal and external demands of the business is possible with a well oiled DevOps machine.

When you have a defined pipeline it doesn’t allow for cutting corners that leads to poor metadata deployed to Production. Creating this path allows for easier training and less guidance needed for the most junior team members. Being able to have each project connected to a set pipeline means that project is likely to meet its deadline. Now, when those teams push their code, it can be not only tested but made sure there is no work being overrode.

Your metadata pipeline can be different per feature, bug, project, etc. A team will need the freedom to push updates and features out differently. Having those definitions and paths will ensure a solution for each type of work the team is doing.

How?

Each stage of Sandra’s pipeline should add value or solve a problem she has. Her team members are overriding each other’s metadata. Having all their sandboxes flow into one environment purely for handling this issue can be resolved with an Integration sandbox connected to version control. Now their many-to-one flow into Production is mapped to another sandbox where overrides can be fixed and recognized earlier.

Her team is also struggling with the QA work and passing of quality gates. This can be fixed by adding a Staging or UAT environment after Integration. Once metadata passes the override issue, it can be tested by their integration tools and QA team. Having positive results in this sandbox is the final needed step before a deployment to Production.

Finally, it is important to create a ‘Hotfix’ environment. This is cloned and copied from Production and continually matches Production. Deployments from a Hotfix are typically urgent and last resort. Every organization needs to be agile and this allows for those emergency deployments.

When?

Sandra will see that defining her metadata pipeline is the next needed step. Her next question will be ‘when should she make the change?’. They have a ton of work in progress, a big project starting soon, and a code freeze in a couple months. The answer is she should start as soon as possible.

Focus one week on completing all ‘In Progress’ work and then make the change. Waiting for those features that have been on hold or lightly worked on won’t be much lost work. Most often, when one gets assigned old requests with some work done, it takes longer to figure out what was started than it would to just start over. Waiting until a code freeze would be too long and code freezes will have deployments from a Hotfix for emergencies.

Defining a pipeline for your metadata will only make working with a deployment tool simpler and easier to implement. Small changes within this process can allow your team to do what it is best at — developing and deploying changes. A tool like ClickDeploy can further a team’s deployments. Start your trial with us today and deploy within minutes!