My Story: From Zero to Hero in Salesforce DevOps

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.

The Challenges

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.

Migration Planning

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.

Implementation

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:

• Feature change

• Bug change

• Hotfix

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 Outcome

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