Streamline Your Enterprise Salesforce SDLC

INTRODUCTION

How often have you worked on a big enterprise where the processes are unoptimized or outdated? It may even be the case that everyone is aware of this issue, though no one seems able to fix it. It feels like almost all enterprise projects move slowly and require many meetings and thousands of emails before you can even take the first steps to transform the process.

Fortunately, I’ve discovered how to transform something on an active enterprise project and move into a new direction with a source-driven development approach.

BACKGROUND

Recently, our team was working on a large Salesforce production instance — let’s call it Arena — that handles approximately 80 million API calls per month. Arena has more than 5,000 active users, more than 20 developers, and around 50 people with system administrator profiles. Additionally, there are more than 1,000 functional classes, a vast number of packages and data, and an IT infrastructure core with more than 50 other systems.

CHALLENGE

Arena was working on a proprietary deployment system that we’ll call Bob. This system enforces an org-driven development approach, and Bob made the process easier for those who had experience with change sets but had never used Git.

Bob can commit changes automatically and promote changes to any connected environment. Though this sounds great, this approach came with disadvantages.

Not only does using Bob require training because it is Salesforce-specific it also enforces its own terminology. Additionally, any troubleshooting requires an advanced understanding of Git processes. Bob also results in complicated conflict resolution and troublesome releases of independent features that might share some metadata. Unless Bob is installed within the Salesforce environment as a managed package-and is integrated with Jira, Github, and all other sandboxes, Bob will slow down production performance, eat storage, and require access to production for end users.

Due to increased costs and a lack of alignment with the rest of the projects using classical CI (at SoftServe it's called CircleCi) using Bob was not the right choice for this project.

In general, it is challenging when there are more than 20 developers replacing or updating any tool that impacts their day-to-day routines. It can become even more complicated when multiple vendors and stakeholders are involved, and different team members have varying levels of experience. Plus, not all tests are in their correct state, and the execution time for RunAllTests is more than two hours!

While options like Bob may have been the right choice in the past, now it’s better to use Salesforce Developer Experience to store your project sources and drive SDLC.

The goal is to implement a system that doesn’t limit any users from working and creates a smooth transition and implementation with fast deployment.

FIRST STEPS

When you want to remove an application from an existing system or otherwise make significant changes, you’ll almost certainly face resistance. This pushback can come from different sources. Sometimes it’s from the people who chose the original technology or those who have gotten used to it and don’t want things to change. No matter where the resistance comes from, when you want to change a core system or tool, you must be able to negotiate.

In the case of Arena and Bob, I learned some valuable insights that may help you as well.

First, be patient. Changes cannot begin immediately. It’s important that your plans are clear and fully supported by your managers and the team. After all, they’re your strongest allies.

Next, stick to the facts. Explain to your company’s decision-makers and other stakeholders what they will gain from this transformation. For example, if improvement reduces deployment time, developers will have more time to focus on other tasks. If you have 10 developers who will each save an hour daily thanks to this system, that’s an added 50 hours per week for new innovations. In our case, after we changed the process, we were able to review our estimation mechanism and definition of story point!

Remember that knowledge is another tool, so constantly continue to invest in your knowledge. Each new book or article you read may give you another point to support your goal of implementing significant change.

Lastly, don’t give up. If you are the engineering team leader, no one besides you and your team really understands the challenges you face. If you meet resistance, you should look for other approaches and methods to reach your goal.

PLANNING THE TRANSITION

Before you start, it is best to have a plan. Important questions to consider include:

• How are you going to achieve this transformation?
• What exact steps and other effort will be necessary to achieve this goal?
• How will this new system or toolset exist and work with your other systems and tools?
• How will you test it?
• How will you troubleshoot and problem-solve if something doesn’t work as expected?

The plan and flow shown below has been successfully used in many projects.

Transition Phases

BEST PRACTICES FOR YOUR TRANSITION

1. Make your changes sequentially
   • Our team performed changes one step at a time.
2. Fail fast
   • This will help you to identify any weaknesses in your new solution.
3. Always have an alternative
   • Unexpected things may happen, and you want to be ready with an alternative approach if something breaks.
4. Test your solution
   • While this may seem simple and obvious, nothing works well without extensive testing.
5. Launch kickoff meeting before each phase
   • Make sure your team is aware of what is going on.
   • Be sure to record these meetings in case some team members are absent, or the team wants to review key points.
6. Get feedback at the end of each phase
   • All inputs are valid and can help make the process easier in the future.
7. Draw diagrams
   • Visual representation of each step will help you to align your team’s understanding.

GIT TRAINING

After many years the world has finally chosen Git as its source control system winner. We no longer need to worry about alternative source control systems.

Nowadays Git is everywhere, and non-technical people can use user interface (UI) clients for it. It’s not as complex as many believe, and it is vital when you work in IT regardless of your role in the project.

I have worked with many tools, and each has its pros and cons, but the simplest for non-engineers is GitHub Desktop. It’s very user-friendly, with numerous features that simplify some standard Git operations. For example, GitHub has a magic button for “Open in GitHub Desktop” that makes the initial cloning steps significantly easier.

The best way I’ve found to explain how to use Git is by playing a Git game found here: https://learngitbranching.js.org/

If you have any Git knowledge gaps, some time spent playing this game can significantly improve your manipulation capabilities with commits!

Also, don’t forget about practical training where students can try committing, merging, rebasing, and other classical operations. Practice is everything, and Git is one skill that evolves constantly.

FINAL STEPS

This is the finished source-driven development approach. We implemented our solution via CircleCi to align with other departments and projects.

Frequently, the biggest fear is what I also worried about when we began this initiative: deployment time.

Thankfully, when you use a source-driven model, it means changes in Git should be reflected in the org. To accomplish this, you must do a full deployment, but only on sandboxes. Today’s average full deployment time is 10 minutes for more than 15,000 metadata components. Deployment starts automatically when changes are detected.

As a result, the time from deployment to the QA environment after PR is merged was decreased significantly. You save time on metadata selection, metadata retrieval, and other manual steps. These steps are now just gone!

So, how did we solve the challenge with test executions? We decided not to block deployment unless components are deployable. This meant the test execution was just informative validation before changes move to a higher environment. The test executions occur on eight developer sandboxes called “test pools.” After each push to the QA branch, we deployed and executed a subset of tests on each of these test pools. As a result, the test execution time takes approximately 30 minutes.

In addition, we also established code analysis procedures in our CI system for Apex and JS, destructive changes, and other capabilities.

At the end of this project, we had a happy customer, happy engineers, green tests, a fast build system, simple releases that made our QA team happy, and metadata organized in a self-documented structure!