My Story: From Zero to Hero in Salesforce DevOps
How moving to an in-house model changed so much
How it was Before
Before I joined an organisation as a Lead in DevOps, they used a mixture of on-prem, Azure and Salesforce technologies to facilitate internal staff and customers. The organisation relied on outsourcing its Salesforce development, where internal knowledge did not exist.
By the time I joined, the organisation had made good progress with recruiting a small team of in-house Salesforce developers to start contributing to improving and releasing changes, with the idea of reducing outsourcing costs.
I started to look at the source code location. Because of the 100% outsourcing before my joining, that company managed the repository. This identified the first challenge, which was repository ownership and administration constraints.
I then came across a history of issues where code merges to production would result in historic changes/fixes disappearing, breaking functionality and requiring rework by developers.
Finally, our in-house development team struggled with the outsourcing team's tools. The tools included Mac-only software and custom Linux-based scripts for building and deploying to Salesforce. Our in-house team were more comfortable with Windows and not working with such custom building and deployment mechanisms.
The First Hurdle
Knowing our challenges, the first hurdle was identifying how Salesforce DevOps would look like internally at the organisation. There were two options:
Internally developed script-based build and deployment solution, where heavy code-based development is required by both DevOps and Salesforce developers
Purchase an out-of-box product that would provide a low code experience to developers, pipeline approaches that suits a Salesforce environment, and a minimal DevOps management need only on highly technical items.
After research, demos, proof of concepts, and consulting with leadership on the financial costs of both options, the organisation and team agreed to implement an out-of-box Salesforce DevOps product. During this decision-making, many Salesforce DevOps companies were contacted, demos were arranged, and test integrations were completed. The team decided to use Copado as the DevOps tool of choice for this company.
So, choosing an off-the-shelf product to resolve your issues immediately is not as straightforward. Copado required the customer (us) to architect our deployment and release pipeline, configure integrations, and set up our sandbox environment for developers. They do help with planning and advice, but it's all on the customer to do it.
However, the first challenge, earlier identified in the blog, was an initial blocker. We had to have administrator control and implement our code practices and branch model in the repository. As the outsourcing company owns this, we planned a repository migration. There were considerations for this migration; some decisions were due to the outsourcing development practices:
Feature/Bug/Hotfix branches - Due to 5000 active branches, only 12 months of branches would be migrated to the new repo. Anything older would be stored as part of the backup
Branch renaming - Rename branches to match our environment setup and for easy configuration in Copado. This helped eliminate legacy naming conventions
Git history - Retaining the Git history was very important for us to identify changes made, when they were made, and who by
Repository host - As mentioned, the organisation already were utilising Azure and On-prem technologies, and development teams were using GitHub. As such, hosting the repository was a simple decision
Access - As part of the repository migration, we would restrict access to internal staff only, resulting in outsourcing stopping. This meant on the day of migration, Copado implementation also had to start
Downtime - Due to the number of configurations, a few days were required to implement and test all configurations. This meant code freeze and no changes to Salesforce solutions
Migration on the day was straightforward; we took a backup of the repository and stored it securely for recovery purposes. We then uploaded our backup copy to GitHub and ran a cleanup to delete branches older than 12 months. Finally, we implemented the branch protections and sandbox branches based on the development environment to link each developer to the Copado sandbox environments.
With the migration of the repository taking place, Copado implementation had to start. This involved installation, configuration, integration, and testing of everything we had architected up until now.
After the Copado installation and user access permissions were set, we had to start designing pipelines and integrating the environments and their stages into the pipeline.
The above image is an example from the Copado docs, but it is slightly similar to what we had designed based on our environments. Each developer had a sandbox environment, allowing them to make changes and test before pushing to the environment above. We had to configure it so that if a developer's sandbox environment was behind on Git changes, the developer had to pull and test before allowing them to push their changes, resolving the second challenge, which was the loss of changes when merges were happening.
Once the configurations and integrations were completed, we had to test the pipeline process by going through each of the following change examples:
Each of these change types has different tests and delivery processes that require us to run and ensure delivery is working. This stage identified numerous configuration issues but allowed us to identify them before going live.
The obvious outcomes from reading this article:
The organisation dropped day-to-day outsourcing
In-house development was enabled, and knowledge is now retained internally
Code security is managed internally and only accessible to internal staff
No missing past changes from Git merges
Low code Salesforce DevOps tool enabling a larger range of developers to contribute
But we also had the following results:
DevOps (I) increased knowledge of Salesforce development and DevOps practices. This resulted in technical support for Salesforce developers within the platform when there were Copado issues.
Salesforce developers were able to increase their delivery of changes to production from 2-3 months (outsourcing procedures limited continuous deployment) to less than an hour
Small incremental changes, less chance of breaking anything, and easy rollbacks if required
Visualisation of releases and changes happening
Training material for Copado resulted in individuals (including myself) becoming certified in using the tools