Salesforce Deployment Options

There are multiple ways to deploy changes in a Salesforce environment: with the Force Migration Tool, a change set, or the app exchange applications available

The first of these, the Force Migration Tool, also known as the Ant Migration Tool, uses the Metadata API to move code/metadata between environments via a series of text commands into a terminal. Using this can be labour-intensive and requires investment in time to set up, but gives you control over your deployment process. It is also well suited for continuous integration and continuous deployment workplaces where there are multiple project streams, developers and environments.

The second option, a change set, is the Salesforce delivered method that allows a collection of features and customizations to be bundled together and delivered from one Salesforce environment to another, where it can be opened and deployed. Unfortunately, change sets don’t support all Salesforce components, they can’t be used to move all functionality over from an environment to an environment. Many, highly used, components, including sales processes, standard picklist values, security model updates, and organization-wide email addresses, must be moved over manually.

Finally, the App Exchange is a huge marketplace for applications created by developers for users and instances on Salesforce. Some of these applications actually enable you to move your customisations between environments. Applications such as Flosum, Copado and Gearset are great examples of this and offer the Salesforce deployment capabilities back to you as users or your developers.

A working example at Trigg Digital

So what do we use at Trigg?

Well, everything! We have numerous clients all over the world using their own methods of moving our developments across their environments in a way that suits them.

Let’s stick to one that uses the multiple options bundled into one by using the Ant Migration Tool and change sets. As a project we have developers who love to code customisations in the Salesforce platform, we have admins who love to create fields, objects, alter page layouts and create process builders and flows then we have the plucky consultants who like to do quick POC’s for clients and developers. In a single org/environment, that would be a headache waiting to happen. I can hear the cries already; “You’ve broken my flow”, “You’ve moved my field”, “Where’s my super-duper awesome thingy I designed to show the client”. Salesforce saw this coming and gave us the ability to spin up sandboxes and development areas for us to separate our colleagues and make specific environments for different requirements to sing along in peaceful harmony. At Trigg, we use this to our advantage. We have a development org, a POC org and a testing org to name a few. 

To start the process, we use our Development Org to make the cool changes our clients need and unit test the development against any criteria we and the client have decided. 

From here we use the plethora of tools at our disposal to move that single piece of development to a Dev Testing org where our testers again unit test the functionality and hold it accountable against Acceptance Criteria and business requirements to ensure that it is doing exactly what it should be doing. Using Change Sets, Force IDE or simple retracing our steps in a different org allows our team to completely dedicate time testing that sole development to make sure that someone else’s half complete development isn’t clouding results.

Once that’s passed testing, we use the Force Migration tool to retrieve that metadata from the org and push it to our version control in GitHub. Using GIT allows us to track our changes and also ensure that our development standards are being adhered to. The reason for doing a retrieve rather than asking our devs to manually add changes to source control is to allow for them to do what they do best and that’s, develop. It also allows us to use our admins to create customisations and not burden them with the really technical stuff.

Using Git we can repeat deployment to further environments like our QA, UAT and production environments. What more can you ask for? Accurate, Quality Assured and Version Controlled code making into your live environment and driving successful adoption of the Salesforce platform, right?

Where next?

Not only are we pushing code between environments, we’re tracking changes constantly in some of our orgs. In large organisations sometimes things can get out of control very quickly and we have accounted for that in our methods. Having daily retrieve jobs running in our key environments stops us missing any small, large or odd changes to metadata that someone might forget to tell us. Salesforce themselves don’t offer history tracking on metadata, but we have enabled that for ourselves. No more do we scratch our heads at what the previous version of our code was or what formula was in the field before we have that stored in GIT. A job that is run on our Dev and our Prod instance returns all the changes we’re looking for and commits them to git on our parallel branches called Dev and Prod. This allows us to merge our code in to what’s existing in production at ease and we no longer heavily rely on refreshes to get other changes in to lower environments. Nifty right?

Another step that we are looking to take is automatic code scans for not only our best practices, but also coding standards and Salesforce’s own developer practices. Something that runs every commit or every day and gives us a report on what’s good, bad and indifferent within our code/metadata gives us the confidence and ultimately our clients’ confidence that our development is fit for purpose.   

Testing is of huge importance to all our projects and developers and taking steps in order to make these either more accurate, quicker and scalable is certainly the way forward. We’re constantly looking for ways to improve and with Salesforce it’s easy to start small and build our way up by introducing Apex Tests, Manual Test scripts and hopefully in the future automated tests. There are tools out there that allow for people to create, run and automate test scripts for the Salesforce platform and even better we can plug it in to our automation pipelines. 

In conclusion

There are some really powerful tools out there for automation within not only deployment but also development that you can use to better improve your Software Development Lifecycle. At Trigg Digital, we are constantly on the lookout for new, better and more innovative ways to deliver value to our customers and Deployment and Development is a great way to build relationships and trust with our customers.

If you are interested in finding out more about how Trigg Digital can help you, then contact us at hello@triggdigital.com