Salesforce Admins and developers have enough to deal with day-to-day. Manually managing the development and delivery schedule for your Salesforce team should not be one of them. Unfortunately, the release management process in Salesforce can be a complicated and unpleasant experience for most developers and trailblazers. The distributed team of developers, admins and technical architects that are required to build and release enterprise-class customer experiences on the Salesforce platform is challenging to orchestrate. Getting that team to work together and deliver releases on schedule every month, week, and even daily can seem impossible.
The scenario is so common. You’ve been preparing for the next release for weeks, but you know it will be painful and full of issues. You’ve done all that you can with your team, so you go through your manual to-do lists… and hope for the best. Worst of all, the moment this release is done, you face another even more complicated release with less than half the time to plan as this one took.
Unfortunately, today companies can’t keep up the pace required to bring their digital business initiatives into production with manual and unstructured release processes. They need to incorporate modern DevOps best practices into their Salesforce implementations. Eliminating the headache of cross-development and release management as a project risk enables organizations to focus on innovation. Mistakes in the development and delivery process have a domino effect. When the system breaks, trust in the software breaks down, usage dwindles, and investments are lost.
It shouldn’t be this way. Developers and admins should love to build apps on the Salesforce platform. Salesforce delivery teams should be able to work effectively together to build and deliver new innovation into the market faster than with any other platform. We call this continuous innovation and delivery.
I have a long history in the Salesforce ecosystem as a customer, a partner, and working for almost nine years at Salesforce growing the platform. Now, at Copado, I’m helping admins and developers (of all expertise levels) get the most out of Salesforce by helping them improve their DevOps processes and achieve a continuous delivery schedule – one deployment at a time – with automated, error-free releases.
But before you try to implement a CI/CD platform for Salesforce, you must first develop a strategy. A good DevOps strategy should be part of a larger governance effort at your company and at the end of the day, technology will be successful if your organization is on board.
Take a step back and understand how you can better prepare your organization for Continuous Delivery. Align your development teams to work together. Are some teams using agile processes while others don’t? How do all the teams test their work? Is it automated and comprehensive? Identify complementary and conflicting teams to allow for a better development process.
Then agree on how you communicate while building apps. Be aware of how updates are shared and in what matters to each group or team, and understand who handles integrations, delivery, and testing environments. Once you have your teams in sync, then you are in the first step in the right direction to employ DevOps best practices.
Now, let’s take a step back to understand the level your organization sits in terms of DevOps maturity. Identify where your organization is today and what the next level looks like, which will help you determine the next steps in the journey toward Continuous Delivery.
Here are the five steps leading to continuous delivery and innovation.
- The first level we call select and deploy, which refers to managing different configuration, development changes, and metadata made across your Salesforce org. When different changes are made in different environments without coordination, this results in frequent overwrites.
- The second level is version control and introduces external repositories to store and manage code and changes. Managing different branches of code and configurations across a team is the best practice for developers but not admins. It may be necessary to introduce some manual quality controls to achieve the goal of monthly releases. The next three levels are where it starts to get interesting.
- The agile release level is where teams should strive to be as soon as possible. At agile release, you build your release strategy around specific user stories and epics from your agile planning phase. Releases are small, aligned to business goals, and released on time. Environments are kept up to date but deployments are still somewhat manual and can accumulate in pre-production.
- At the intelligent automation level, you can start to have some fun. Admins join developers aligning agile planning to a unified version control strategy that can incorporate any number of salesforce environments, sandboxes, and even scratch orgs. Automated tools for packaging, testing, and releasing innovation are employed at every stage. As automation takes root, the team is able to move to predeployment at a daily pace including back deployments. However, with all of this, release to production is still a manual step managed by IT.
- At the fifth and final step, continuous delivery, you automate that last step of the release to user phase. Here, Salesforce apps are written for automated and regular release. The business is fully aligned to technical execution and the process is governed by real-time monitoring and a compliance hub.
About the author
David Brooks is the VP of products at Copado. He is a serial entrepreneur who has worked at 6 startups with 3 successful exits over the past 34 years in the valley. He joined Salesforce.com just after their IPO in 2005 to build AppExchange for the next 8 and a half years. He ran a third of the Force.com teams during his tenure.
Happy data collecting!
I want to hear from you!
What is one thing you learned from this post? How do you envision applying this new knowledge in the real world?
Let me know by Tweeting me at @automationchamp, or find me on LinkedIn.