Redgate, like many companies before us, has switched to Salesforce for our CRM system and experienced huge improvements as a result. It’s proved invaluable, allowing us to delete millions of lines of code and remove gigabytes of on-premises data that we previously had to manage and back up. In amongst all the benefits, however, there was one thing that stood out as problematic: the deployment process could be time-consuming and frustrating.
Redgate has a wealth of experience in creating successful deployment tools for SQL Server, and this started us thinking about whether we could help to improve the Salesforce deployment experience and develop a tool for the community to use.
Understanding the problem
So we set out to speak with as many people as we could, to understand what they liked about Salesforce and whether they found particular areas problematic. The response was extremely positive, but after a while we started to notice a pattern that echoed our own experiences: almost everybody mentioned deployment and, when they did, it was with some trepidation. We even spoke to a few people who’d developed their own tools and processes to help them when it came to release day. Finding lead users who are feeling the pain enough to try to create a solution for themselves is a great sign that you’re onto something (in fact, one of these lead users now sits on our expert panel).
Wanting to dig deeper into the issue of deployments, we spoke to people about what sort of applications they were building, how many people were on their teams, how many organizations they had, how often they deployed changes, who was responsible for deployments, how long they took, and how often they went wrong.
Deployment is deceptively complex
On the face of it, deployment seems simple enough: it’s the process of moving changes from one organization to another. But you don’t have to look far to see the sorts of problems people come up against. Organizations can quickly become extremely intricate, with huge numbers of objects. Dependencies between objects adds a further layer of complexity. Making just one small error can potentially cause a deployment to fail.
Salesforce is a productive platform, and we spoke to companies who had two or three developers or admins maintaining organizations with a few thousand users. Salesforce users are smart, so they quickly figure out that they can create the functionality they want without making a request of the development team or expensive consultants. They just go ahead and make the necessary changes. But if you make a change without going through QA (for example, if you change a picklist value or field data type), this can lead to failed tests and a stressful release day.
How do teams approach deployment?
As Salesforce devs and admins, we can take a few different approaches to deployment. For some people, it’s not even a problem, because they never actually deploy. We met several people who work almost exclusively on greenfield projects, where they make updates directly in production until the project is complete. One example is that of a consultancy focused on helping nonprofits make the best use of the platform features available to them through Salesforce Foundation. For these nonprofits, this often involves migrating from an old manual system to a cloud application. Working directly in production can make sense when there’s no existing application to keep running and it’s important to keep costs to a minimum.
At the other end of the spectrum, when there are existing applications and users to consider, some admins take it upon themselves to manage every change that makes it to production. They often make each developer on the team work in their own sandbox, and all changes need to flow through the admin so they can ensure that the changes won’t negatively affect the business. As teams grow, this “gatekeeper” role can become more than one person can handle – not to mention a little tedious. At this stage, we found that people often began to use agile methodology, automating deployment and moving checks and code reviews earlier in the process.
What do people currently use to help with deployment?
Salesforce has a number of tools you can use for deployment, with most companies using Change Sets and the Force.com Migration Tool for different usecases.
Change Sets
This tool is available via the Salesforce web interface. Organizations are configured so that they can send and receive changes between each other. You look through the available objects in the source org and choose which ones to deploy. Once the change set has been built, it’s deployed and staged in the target org. Switch to the target org, accept the changes, and you’re done. The two orgs now have the same metadata, and therefore the same functionality. This is a great workflow for quick changes, but it can be hard to scale when you have many developers working on a team or many environments to manage. While it does offer a basic dependency analysis, it’s cumbersome to use for larger deployments. Change Sets doesn’t support deleting files and is limited in power. However the GUI makes it accessible to a wide range of users. As a result, it’s often used as the starting point for smaller orgs or for quick changes.
Force.com Migration Tool
This tool is based on Ant and gives more fine-grained access to the deployment process. It’s useful for automating the process or controlling it more accurately, and creating artifacts that can be reused or recorded so that complex processes can be pushed or pulled in whatever direction is required. Generally we found this was being used when a project outgrew its early stages, whether in terms of code size, age, functionality, or team changes. The Ant tool, when compared to Change Sets, is analogous to a command line vs a GUI: the GUI might be easier to get started with and is perfect for beginners, whereas the command line has a steeper learning curve but brings greater power. The lack of GUI, however, is a barrier to many non-devs, and running deployments with intricate dependencies often requires manual code editing which is error-prone and time-consuming.
Simplifying deployments with Gearset Deploy
Having spoken to lots of Salesforce customers, we felt confident that there was an opportunity to start building a Salesforce deployment tool which was powerfully-featured yet simple and reliable. In essence, something that makes deployments just work.
We designed Gearset Deploy to be a powerful yet user-friendly tool which makes managing deployments a breeze. It’s a cloud-based app which compares two organizations and highlights the differences between them. In just a few clicks, new, missing, and different objects can be easily identified and deployed.
Profiles and permission sets, which seem to cause even the bravest to tremble a little due to the complex dependencies associated with them and the potentially catastrophic effects of a mistake, are managed through our unique dependency analysis. Gearset Deploy automatically determines and displays any dependencies, ensuring your deployments are successful while only deploying the changes you need.
Gearset Deploy also supports deleting files (destructive changes), making it significantly more powerful than Change Sets for advanced orgs, while having a user-friendly GUI which is usable by devs and non-devs alike. Being a cloud app, Gearset Deploy is accessible on almost any device with a web browser, including Windows, Mac, Linux, Android and iOS. With its mobile-optimised design, you can run a deployment from your phone in just a few taps, allowing you to remain productive while on the move.
You can use the desktop version of Gearset Deploy to synchronize between your Salesforce org and your source control system, allowing you to easily share changes with your team.
The Salesforce deployment landscape
Some people work directly in production, which is fine in certain circumstances. Sometimes there are no existing applications to disturb or users to worry about, and financial restrictions mean that fewer environments are a necessity. It makes sense that consultancies working with charities and nonprofits would work in this way.
At the other end of the spectrum there are teams who are striving to adopt agile practices and using all the tools that support that methodology. They might have worked on a .NET or Java stack previously and are now turning their hands to Salesforce, and they’re applying a lot of existing development and deployment techniques to this still-new platform.
The consensus is that deployment in Salesforce can be a difficult process to manage, and that extablished best practices only partially fit into the typical development lifecycle. Salesforce has become an integral part of many companies – by aiming to simplify the deployment experience, we at Gearset hope to help these companies get the best out of Salesforce.
You can find out more and try Gearset Deploy at www.gearset.com.