Date published • 9th August 2018
Now that you (hopefully) read my rants on my views and the tools involved in DevOps for Salesforce, I'm going to show how a common development lifecycle works in Salesforce today.
I'm going to leave this slightly agnostic to the tools, focusing more on the steps for development and releases that in my view are needed for a common Salesforce implementation. This includes DX use, I'm going to mention it here and there, but won't go into detail in this post, as it will have a dedicated one next in the series.
This post covers just a single org lifecycle, as you can extrapolate to as many orgs you need by applying a flow for each. This assumes that the orgs are completely independent and that there's a valid use case for that. For some good info on determining if your company or client needs one or multiple orgs, check this article, it can probably be a bit outdated on some details, but it's a very good starting point.
Let's get to it, then.
First of all, I have to say that the amount of environments, repositories, branches and types of testing needed will depend on the size of the implementation, so I'll try to frame it to the main, and more common, steps. I'll point out some of the differences and how to adapt to different things as we go along.
One of the most important things of having flexibility and adopting the DevOps culture, is that each team chooses the scale that is appropriate to them, there should be nothing forcing teams to work in one way or the other too strictly (as long as the culture is adopted, of course!). Below, I'll explain how I usually like to structure the most common implementations.
Project and environments
I'm going to base the flow on a project where there is a single stream of work, with a medium size team, in a brand new org, for simplicity.
Note: if the org isn't brand new, the existing source must be pulled down and put in source control in the appropriate way. In my next post about DX (or not DX), I'll mention this in more detail, and touch on how to break the source in packages (or not yet, maybe?).
The core environments we should be using for this are listed below.
Let's start with the less stable ones, used for in-sprint work, I'll call this set of environments the "dev train":
Now, let's move on to the more stable ones, the ones where we'll only put release candidates, on the path to production. I've heard this called the "release train", so I'll steal that term.
Emergency fixes will need the following environments:
Additional environments are often required for the following situations, among others:
For big enterprise level implementations, in order to adapt this structure to allow for multiple work streams, you'll need to replicate the "dev train" environments for each stream, as needed. You'll also need to add a consolidated CI (CCI) environment that will be used for automating the builds validating the correctness of the integrated codebase for a particular release candidate that includes more than one work stream. This new environment could be a developer sandbox or ephemeral scratch orgs, similar to the ones for CI.
It's important to note that for implementations with many work streams, you'll need A LOT of collaboration, communication and synchronising (think of implementing deployment windows with tight deadlines, making streams miss windows as they're not met). Usually, in this case, a team is needed for each work stream and an additional team is required for managing the "release train" and governing the lifecycle.
As we discussed in previous posts, We'll use Git for source control, so I'll explain the branches that are needed for the common scenario we're dealing with. I like to use the Gitflow workflow (or close enough) that you can find explained here. Top to bottom descriptions:
Step by step summary
I'll try to keep it light here, as it can get too cumbersome, I will hopefully cover the highlights
For each user story (or bug), the following happens:
This goes on, until the sprint's features are finished, bugs are ironed out, everything is demoed, tested and validated. Life is good (so far).
Considerations and takeaways for the dev train:
Sprint's tasks done, the following things happen:
Considerations and takeaways for the release train:
Fully automated pipeline from dev to prod: dream and considerations
In some technology stacks, it's possible (and usual) to automate everything and go into production without a lot of hassle, really frequently. Rolling back easily if something goes wrong and so on. Think of mobile apps updating daily and things like that. That's the dream, right?
If you're able to do this with your Salesforce implementation, you're a really lucky individual (or team), please let me know how you did it, I'd like to try it.
I haven't done it yet for the following reasons / considerations:
And that's it for this entry, next one will be about DX and whether I use it or not, how and when. Looking forward to that one!
Please feel free to comment with suggestions, considerations, things I missed. Anything!
Ivan, Head of Architecture
If you would like to know more about what we do, we’re happy to answer any questions you may have for us.
Share this article: