[Salesforce / Release Management] Automation for the win!

You hate manual tasks and you are working on a Salesforce.com implementation? Then get a pen, a piece of paper and install & set up Copado.

Why Copado? Because it’s a great solution to manage releases of and with Salesforce.

Why pen and paper? Because it’s a great and versatile tool for drawing your current process and highlighting automation possibilities.

Things are ok. But can we make it better?

A couple of weeks ago, we have installed and set up Copado to manage our release process.

Committing to and deploying based on Git version control turned out to be easier and more secure than working with change sets (finally you can track who screwed up your stuff and restore it).

Next, we took some time to think about the people involved in an implementation, and how projects can work better as a team to release faster and better.

So now, as our team is aligned and everyone has confidence in the process, during the retrospective, the team decided to further improve the process and automate some of the steps.

• Avoid manual step after deploying a custom setting to change endpoints
• Ability to commit and deploy dashboards with running users, because it is just annoying
• Mitigate bad development practices hard coding IDs
• Send a notification to testers, once a user story is in the test environment

Deploy the same, but different

There are items in software development, which need to be modified based on your environment. Typical cases are integration endpoints, which change depending on if you want to connect to a development, test, or production instance of e.g. SAP. In Salesforce, you can add further items to the list, like IDs, if you want to exept an admin profile users from a validation rule. You can hardcode it as part of the formula (bad, think about kittens and unicorns) or you can put the ID in a custom setting, which is better, but still requires a manual step after deployment, updating the setting record in the target org.

Here is where Copado can help you to automate those steps with the concept of Environment Variables.

If this is too technical and not emotional enough, we will get rid of any manual changes related to hard coded IDs or URLs. Regardless if they are part of a Custom Setting, Validation Rule, Visualforce Page or Class. Believe me.

How does it work?

If you define a specific string, Copado will recognize it and translate it to a variable name, which you define. And upon deployment, it will replace the variable with the string you defined for your target.

Setup Environment Variables

In our case, we will set up an enVar (Environment Variable) for an endpoint, a user and the Admin profile Id.

1. Get a clear view on your current unique strings. A table works best. Feel free to use pen and paper, if you like.
   
   
2. In Copado, go to your active Deployment Flow, and click on the “Manage Environment Variables” button.
3. Create a new Variable with the name you prefer. To keep an overview, I prefer to use a naming convention: elementType_usageOrItem
4. Populate the string per environment or copy&paste from your table to Copado.

Follow the same steps for the other strings, and you will end up with something like this:

Use Environment Variables

So, let’s go ahead and deploy those items. The running dashboard user is part of the xml file, so it’s ok if we just commit it. The same is valid for hard coded IDs in classes or validation rules. However, the custom setting is stored in a record, so it needs to be handled differently.

1. Create a Copado User Story.
2. Go to “Commit Changes”, select the dashboard, underlying report, endpoint custom setting (in case it is not deployed yet) and the validation rule with a hardcoded Id.
   
   
3. Provide a commit message, and click on “Commit Changes” to finish the process.
   Take your time to review the commit and see, if items have been added to Git as expected. On the dashboard, you will see that the Running User tag has been replaced with the variable name. The same happened with the Id in the Validation Rule.
   
   

   

4. Ok, so commit is done, but we still need to account for the custom setting. On the User Story, scroll down to the “Deployment Tasks” related list and create a new task: after deployment, type: “Custom Setting”, select your setting, and click on “Get Custom Setting Values”
5. Once you have the list, select the setting records you need, and save the step.
   
   

Well, this is the moment!

Will it work, will it deploy and replace?

Check the “Promote & Deploy” checkbox on the story to see Copado Magic at work.

Deployment Done.

Log into UAT.

A quick check…

All items were resolved. Perfectly!

Apart from deploying the custom setting, Copado has moved the setting entry, and exchanged the URL in the Target field correctly.

The Id in the Validation rule was replaced:

The Dashboard in UAT has the expected CEO running user:

As Copado applies this mechanism to all files, with a single entry we can account for hard coded IDs or URLs in all Salesforce Metadata, including visualforce pages or classes.

Process Automation

Ok, now the deployment is done, the user story is in UAT, and although we don’t have to update IDs, we still need to notify the tester that the story is now available for review.

Easy, because we are working on the Force.com platform, and Copado provides all the information required.
When a story is deployed to the next environment, the Field is updated by Copado automatically (Dev1 → UAT in this case). Also, there is a Test-Script Owner field on the Story, which is linked to a user record.

In technical terms: We have a DML operation and an email on a lookup parent record, so we have tons of options.

Which salesforce automation tool do you prefer? We can use Workflows, Process Builder, and Apex to fire an email to the user story tester or to a generic email address of the test team.

But email? This is so SAP. What about a chatter message instead?! Process it is.

Create a new Process on Creation or Edit of the story record, to fire for all Stories where:

• The “Test Script Owner” field is not empty (Test Script Owner → User Id).
• The “Environment Name” field equals “UAT” (Environment → Environment Name).

Next, create an immediate action of type “Post to Chatter”.

To get the notification right, you only need to consider, that @mentions from process builder require square brackets: @[ mergeFieldOfAUserId ]

If you cannot find the Chatter action on the User Story, enable it for the User Story object in Setup → Feed Tracking.

From now on, when we deploy a user story to UAT, there will be a chatter message on the record and the tester will get notified too (also via email, depending on the settings).

Copado & Force.com: A lot of value for little time invested

Now you might want to know how much time and effort it really takes to set up this type of automations.

To be honest, it took me longer to go through all environments and get the correct values than to set up the environment variables. But in most cases, projects have this information as part of their org-refresh steps documentation.

The main “difficulty” setting up the process was getting the @mention syntax (you are welcome 🙂 ) and improve on some type-os.

It is so incredibly easy to automate even complex scenarios that I set up another action for user stories in UAT to get ahead of my team requirements: Run all unit tests in UAT. But not as part of a deployment, because it’s too easy and this might slow down the deployment. Instead, it should happen after the deployment is finished successfully.

The only thing to do here is to create another condition in our Process (Environment = UAT), and create an action of type “Apex”.

Copado provides a set of helpful methods, which can be triggered in Apex or from the Process Builder, and the one we pick is “Invoke Run All Apex Tests for an Org”. As a parameter, we provide the Org Credential Id of the user story.

Now all apex tests will be run, once a story is successfully in UAT.

Done. It took longer to write about it, than to actually set it up.

One platform. A lot of possibilities

Usually, the tools for committing, deploying, tracking/managing stories and testing are separated. But Copado puts all of it on the highly flexible Force.com platform, so that users can tweak it how they like.

• Automatic deployments to Stage once testing is done? Create a Process Builder to check “Promote & Deploy” once there is a successful test execution record.
• A nightly validation deployment of all stories in Stage to Prod, just to check if there would be any issues? Well, you would need Apex to bundle the user stories and fire the deployment. Basically Query & create records.
• Auto-execute regression testing after a deployment? Record your Selenium Script and add it to be executed after deployment to a certain environment.

You can even go crazy, read the information on committed metadata and auto-deploy only if less critical items such as Report Types have been committed. Dev to Prod including a sync back to Dev2 and the only human intervention would be the commit process (include an approval on QA though. We still have to follow the process, and you don’t want testing to be mad at you).

If this is too technical, and too little emotion, maybe this explains better how it feels now to release features: