Monica Thornton Hill is a Solutions Architect at Fusion Risk Management and one of Gearset’s DevOps Leaders Alumni.
Planning and creating a new development lifecycle takes time and resources. In this post, I’ll help you identify a better software development lifecycle for your Salesforce team and take the right steps towards implementing it.
What is a software development lifecycle?
If you’re using Salesforce, then you’ll already have some form of software development lifecycle in place — new features are requested, built, and released to end users. A software development life cycle (SDLC) describes the stages that new development takes from build through to release, as well as the processes and tooling that allows teams to do this.
An SDLC sits within the bigger Application Lifecycle Management(ALM) process. ALM includes additional concerns that come before the SDLC, such as defining requirements for the software. It also manages your software in live environments, considering the maintenance and governance of the release. For Salesforce teams that are just starting out with refining their release process, it’s best to focus on improving your SDLC before you move onto concerns about the wider ALM process.
When you’re starting out with building an SDLC, you’ll find the same suggestions for the phases of the lifecycle over and over again:
- Discovery Phase: investigating your user requirements and choosing what to build to satisfy these.
- Source Control Set-up: using version control to track changes.
- Development Phase: building new or updating existing functionality.
- Testing Phase: testing your build, with unit tests for example.
- Acceptance Testing: having end users test your new build.
- Product Release: releasing the build to a live environment.
Most Salesforce teams already follow the discovery, development and product release phases — but, how do they then begin to incorporate the other three phases? The limitation of this commonly given model is that it doesn’t provide practical input on what process, culture and tooling need to be introduced to get all of these phases running smoothly. Keep reading for an introduction to the principles and practices of a Salesforce development lifecycle, and some suggestions of how you could implement them.
Software development methodologies
Every Salesforce development lifecycle is underpinned by a methodology: the attitudes and principles that shape your approach to development. There are a variety of different Salesforce methodologies out there, and each has its own strengths.
Waterfall methodology
In the waterfall model, your Salesforce development work is broken into distinct phases as it moves towards release. Operations, if present at all, are siloed from the development process.
Salesforce teams using the waterfall model will wait until an entire project is complete before releasing it to their production environment. This is a risky approach — you could only discover a bug that came from week 1 of development work when you release 10 weeks later. It also means end users will only begin to experience value once the entire project is complete.
Plus, the challenge (and potential risks) of releasing an entire project in one go can make release day incredibly nerve-wracking for Salesforce teams. As a result, the waterfall model is workable for small teams, but is far from ideal.
Agile methodology
The agile method was designed to be more flexible than the waterfall model. It seeks to encourage collaboration between the phases of software development, to help reduce bottlenecks.
Teams using agile methodologies have smaller, frequent releases, aiming to quickly get value to the end user, rather than waiting on a single product release. This makes agile methodology far more reactive — agile teams can identify and address new challenges or opportunities early on in their development cycle.
DevOps methodology
The key similarity between DevOps and Agile is that both emphasize small, frequent releases. But, DevOps takes this a step further by integrating monitoring and feedback into the development process. This is done by bringing operations teams into the software development lifecycle, ensuring that feedback on code quality and user experience is continuously fed into the development process.
As a result, Salesforce teams with a DevOps approach are generally higher performing because regular feedback allows them to continuously improve. DevOps teams quickly get value to their end users and are able to resolve problems swiftly. This has huge benefits for your culture and staff wellbeing, reducing bottlenecks and improving collaboration.
Understanding the various methodologies that you could use in your Salesforce development lifecycle will help you identify your current approach and think about what you may want to change.
Key considerations before changing your Salesforce development lifecycle
Could your Salesforce development lifecycle be better? In truth, all of ours could be. But no matter where you’re at, you can only make the right steps to improving your process by auditing your current approach and outcomes. Though this is easier said than done, as it’s hard to understand what needs to change in a process that your team uses daily.
To help with this, here are a few questions to ask yourself when deciding on what changes to make to your Salesforce development lifecycle:
Are you able to keep up with demand from end users and the business?
Whether that be creating a new feature, optimizing an end users’ workflows, or better supporting marketing and sales targets, you’ll need to step back and consider how often your team is meeting external demands and expectations. If you consistently find your projects going over budget and dragging on, this should be a sign that your process needs to change.
How often are you releasing?
You may be keeping up with external demands and your own goals by getting an entire feature live in one large release. But, what if you could allow end users to see some value of your work before the feature is totally complete? This is the idea behind the frequent releases in Agile and DevOps methodologies — getting value to end users incrementally, rather than in one large release at the end of a project.
Small and frequent releases also help you to identify bugs more quickly and reduce the risk of each release. So an increase in the frequency of your releases, however small, should be the first step in changing your Salesforce development lifecycle.
Are you testing your releases?
Finally, testing is a critical consideration for your lifecycle — it ensures the success of your deployments and is the final requirement when you’ve completed your product release. There are a few questions to ask yourself when considering your testing.
The first question to consider is where are you testing? You shouldn’t be doing this in production. Rather, use a sandbox as a close copy of production, to give you the best indication of whether your release will affect your live environment.
The next question should be what types of tests are you running? There are many different types of tests required for robust Salesforce releases, but you should be using:
- Unit testing, which ensures the quality of your Apex code and Flows, if your team is enforcing flow test coverage.
- User acceptance testing (UAT) that allows your end users to test out the release in their UI.
- Regression testing, that ensures new releases don’t break or alter existing functionality.
- Performance testing, which can be automated if these tests are repeatable.
- Quality assurance (QA) that checks that the release fulfills its goals. This can be done through peer testing within your existing Salesforce development team, rather than a dedicated QA team.
Using these questions to understand any weak points will then help you to identify what can be changed to improve your software development lifecycle.
What are Salesforce-specific considerations?
There are also some nuances of the Salesforce platform that you’ll need to consider when altering your software development lifecycle.
Salesforce development and operations teams aren’t strictly separate
Salesforce teams don’t run operations in the traditional sense. Where standard software teams may have a distinct ops team to monitor live environments, Salesforce teams generally rely on end-users’ reports or failed tests to flag issues.
This means that DevOps for Salesforce isn’t trying to integrate a separate operations team with a development team. Rather, Salesforce DevOps is ensuring that feedback from end-users and testing is brought into the development process. This quirk actually makes it far easier to introduce DevOps practices to Salesforce than other platforms!
Version control is not a standard for Salesforce teams
More and more Salesforce teams are adopting source control but, as a whole, the Salesforce ecosystem is behind other software development teams. This is because of concerns that source control is unnecessarily technical and cumbersome for quick declarative changes.
But version control for Salesforce is rapidly becoming the gold standard, helping teams improve quality controls, avoid conflicting changes with increased transparency and collaboration while keeping a full history of changes for easy rollback should something go wrong.
There are some persuasive benefits of source control: quality control, transparency, collaboration, and resilience to risk. On its own, implementing source control doesn’t solve a team’s process problems, but inherently grants improvement in those areas.
Salesforce holds unique value for your business
Salesforce development work has an unmatched value to the wider business. With 98% of teams now reporting that Salesforce is critical to their business objectives. This adds pressure to choosing the right Salesforce development cycle to ensure the business is getting maximum value from the Salesforce investment, and that such a vital system has as little down time as possible.
Every Salesforce team is different and so their ideal software development lifecycle will be different. Rather than prescribing a ‘one size fits all’ approach, let’s look at key steps to any development cycle that can help you move towards a more mature and robust lifecycle that suits you.
Before diving in, it’s worth noting that a mature development lifecycle can’t be achieved overnight. You’ll need to phase your adoption of new tools and processes, implementing each one iteratively, checking-in often with your team for feedback and assessing how it affects your performance.
An example of building your SDLC
Here’s an example of how a team could iteratively implement new processes and tooling to move to a more mature development lifecycle. This is not prescriptive, simply an example:
Beginning by testing in your staging environment
Once you’ve implemented the DevOps best practice of testing, you’ll be making changes in your development environment and manually deploying them to a staging environment (not production!) where you run your tests.
You can then develop this lifecycle to include running your tests in a QA sandbox before they’re deployed to production. This is an opportunity for user testing to be completed in a separate environment to code based testing.
And finally, you can introduce a stage sandbox as the last environment that features pass through before production. The stage sandbox should be a direct copy of production, that also houses your changes that are about to be deployed to production.
Introducing a continuous integration job to move changes
Once you’re comfortable with running tests in a staging environment and have reliably successful deployments, it’s time to begin with some more advanced DevOps tooling and practices, such as version control and CI/CD. While it is generally recommended that teams establish version control before they implement automation, teams that are a little more anxious to use Git may benefit from beginning with a single CI job.
You can introduce a single continuous integration job to move changes automatically to production. Your CI job can also continuously run unit tests against these changes and prevent anything from moving if any of the tests fail.
Understandably, setting up automatic deployments can be intimidating for teams that are used to moving changes manually. There will be some metadata types or types of change that you won’t feel comfortable with automatically deploying, namely those that are potentially disruptive to logic in your org and could impact existing data, like Code, Flows and Validation Rules. You may also feel uncomfortable with deploying destructive changes.
But, it’s less risky to automate other metadata types, such as:
- Metadata types that don’t affect your automation within Salesforce UI
- Non-destructive changes
- Declarative changes that your team feels comfortable with automating and can provide value quickly, such as: Page Layouts, Custom Fields, Lightning Pages, Email Templates, Reports/Dashboard, Permissions
This is a tiered approach to deploying your metadata — beginning with the lowest tier of ‘least risky’ metadata types, and knowing that in future you’ll have a development lifecycle that supports automatically deploying destructive and logic altering changes as you add in additional CI jobs.
The time spent establishing even one successful CI job will bring huge long-term time benefits, by cutting the time usually spent manually configuring deployments and getting value delivered to end-users sooner.
There’s also some nice cultural advantages of beginning your Salesforce lifecycle changes by introducing a single CI job. By taking a small step to automate non-destructive changes, you’re beginning a big cultural shift to get the team familiar with automation and the idea that there’s a source of truth other than production.
CI jobs are also hugely beneficial to admins, particularly those who are used to making quick fixes directly in production. Instead, stage can be used for these fast-tracked fixes, keeping development work out of production.
Introducing your first CI job is simple. As your testing is already completed in QA and your changes are housed in your stage sandbox, you can easily automate the final deployment from stage to Production, safe in the knowledge that these changes have been tested in an environment similar to production so they won’t break production.
Getting to grips with version control
With automated deployments in place, you’re ready to introduce version control into your software development lifecycle. Version control acts as a single source of truth, that tracks all of the changes made across your team. This keeps a full audit history of changes made as well as highlighting conflicting changes, so you don’t accidentally overwrite a colleague’s code.
There are several different version control providers, but Git-based version control systems are the industry standard. There’s also no single best approach to version control, so it’s important to choose the right Git branching strategy for your team as well as the right hosting provider.
Introducing version control to your Salesforce development lifecycle doesn’t have to be a total overhaul. As you can see below, we’ve only added a release branch and a main branch to the stages that work passes through before it reaches production. The main branch can be your new source of truth, which means you may not need staging anymore.
Once you’re a little more confident with version control, you can set up your CI job so that it automatically deploys changes to a sandbox from the branch after a successfully merged pull request. This sandbox can then act as your testing environment before you then open a new pull request to move work down to a later stage.
Putting it all together
As you iterate on your development lifecycle, you’ll be building on top of the foundations laid in the previous stage. That’s why it’s important to take the time to implement each stage successfully, rather than rushing to get everything done as quickly as possible; if you keep adding to a workflow that isn’t running effectively, it’ll become increasingly difficult to unpick and rectify.
Here’s an example of how each of these stages might build upon one another as you move towards a mature Salesforce development lifecycle, that harnesses CI jobs and version control.
How do different roles fit in the development lifecycle?
Altering your software development lifecycle requires buy-in from your entire Salesforce team and the wider business because you’re changing processes, tooling and culture. Creating the best development lifecycle for Salesforce cannot only come from top-down, and will require input and feedback from all stakeholders.
Changing tooling and process will affect each role slightly differently:
Salesforce administrators
It’s often the case that Salesforce Administrators don’t come from a development or computer science background (and not all Salesforce Developers do either, like myself), so it’s totally expected that adopting DevOps processes and tooling will come with a learning curve. However, admins also hold a unique role in Salesforce DevOps processes, as they have a great overview of both development work and how releases are affecting end users.
Depending on the team, it will take time and communication to get on the same page about concepts like branching strategies, pull requests and conflict resolution, and using Git in general. This is why it’s incredibly advantageous to use a tool like Gearset, which intuitively integrates with different source control applications to empower your teams.
Salesforce architects and developers
Architects and developers will have a strong understanding of your technical processes, which will help them to evaluate which changes to make and which tools to use. It’s also critical to have their buy-in when changing your development processes, as even one person not following the same protocols can derail the entire team.
End-users
Your end-users are a critical asset to your operations considerations. So, your Salesforce development lifecycle should foster a feedback culture, which encourages input from end-users through user acceptance testing and validation, and feedback on how a release is functioning in live environments.
Plus, end-user buy-in is necessary while you’re altering your development lifecycle. Processes will change, and both deployments and testing will become more frequent — end-users need to understand why these changes, which may initially slow things down, are being implemented and be willing to give feedback on how they’re affecting their roles.
Decision makers and the wider business
Finally, decision makers and the wider business need to understand why you’re altering your development lifecycle, appreciate the potential benefits, and provide support. Practically, this support will come from budget and resource allocation, but there’s also cultural shifts that will come with process changes — the wider business needs to accept that projects will be released gradually, testing may become a (worthwhile) blocker, and feedback will be given throughout development work rather than as an appraisal at the end.
Are you ready to champion a new development lifecycle?
If you’re keen to dive further into the principles and processes covered in this article, head over to DevOps Launchpad, the free training platform for Salesforce DevOps. Their courses cover the principles, processes and technical details covered in this article. With over 10,000 users already making the most of this free training platform, why not give it a try for yourself?
If you want to experiment with new processes, such as version control or CI/CD, try it for yourself with a free 30-day trial of Gearset. Or get in touch to book a tailored demo with our team.
