Mastering Salesforce DevOps, Andrew Davis

Mastering Salesforce DevOps, Andrew Davis

At Dreamforce I’ve been lucky enough to be invited for Copado event, where Andrew Davis signed his new book about DevOps.

DevOps – topic about which I don’t know much, which doesn’t mean I cannot argue with our developers and also topic I always wanted to learn more (and looks like I’ll just the day after CzechDreamin).

Never mind, I got the book (445 pages) and have something new to read and think about. Incredible what can be done and how well it can run. Here is my summary and would be great to have a coffee with someone to talk about their view about this.

Interesting to note that almost all of these „DevOps tools“ are helping to solve problems that simply do not exist for Salesforce users. Simply moving to Salesforce solves most every problem with infrastructure, security, monitoring, databases, performance, UI, and more. One reason Salesforce users have been so slow to adopt DevOps practices is that most of them are simply not needed. Sort of.

DevOps is not only about the technical thing, it is about mindset and changes in the company as well. You need to build a force which will push it forward, you need to educate people and remove obstacles. Start with finding influencers, which might not be the one high in hierarchy but those who help others, and get them on your side. And then educate others, via multiple channels, message it again and again in small bites. Andrew did „DevOps December“ and I feel we need the same, as just lately I asked about CI to be setup for one of my projects and had to fight hard to store metadata in the DX format, just to learn later on that they convert it all to metadata to be able to push it via Ant, because they know how it works. So disappointing.

The great debate of scratch orgs/sandbox/multiple sandboxes (one for each dev), org development model versus unlocked packages, one repository versus multiple. And also question how to incorporate admins into the whole flow. There probably isn’t silver bullet and we can have a lot of drinks while talking around this. As well as abound what metadata we shouldn’t track, because … because do you really need reports being done in scratch org and stored in repository or is it easier to make them in production on real data?

Also – one sandbox for each developer or shared sandbox? I prefer the shared one as I can see immediately changes done by other, at the same time developers want their own because … I don’t really know. Also one thing I hate about DX and scratch orgs, that when I need someone else work to be done first I still need to merge their branch into mine to have the last version, while in single sandbox I would see it immediately. It somehow sounds easier.

Metadata or Salesforce DX format? I prefer DX as it will split all those fields out of the one big object file in metadata format, it should better handle profiles but still it looks like proper CI supporting Salesforce will be handy to use (luckily Andrew list a few of them including their comparison).

Why Process Builder use the version, it is way easier with workflow. Such a great question and I never had answer, but here it is (remember that Process Builder uses the same framework behind as Flow):

Flows are asynchronous and may be waiting for user input for many minutes. Flows store the user’s state in FlowInterview object, along with which version of the Flow is being used. Even if a different version is activated while a user is still progressing thorough that Flow, they will be able to complete the process using the same Flow version they started with.

DON’T CHANGE ITS NAME – when you rename field, label, what ever, take a cue from Salesforce and don’t change its API name (if it is already in production). Still remember last project where we regularly rename things and then had to remember to put the old names into the destroy package. That was a pain.

How to transfer configuration? It isn’t suddenly about developers, you need to understand the structure, which might be complex and large at the same time. Using REST API and Get Updated calls to get the last changes might help with getting just the updates and thus minimising data transfer.

Number of deployment per day per developer - 2015 State of DevOps Report

You might believe that bigger team means slower deployment, but with the proper DevOps tools in place the opposite is true – the large team with good infrastructure deploy more often, meaning quicker and easier deployments.

It is also good to follow the practice that broken build has priority, still remember from one project how we weren’t able to deploy for a few days, because it just wasn’t priority, consultants didn’t have a clue what the errors are about, they didn’t make sense to developers either, so we tried to ignore them for a few days. Surprise, they didn’t go away.

Naming Conventions, Dependency Injection, Event-Driven Architecture, Separation of Concerns, Enterprise Design Patterns, Packaging Code, Trigger Management – difficult topics for non-developer, but great eye-openers. I do know about FFLib and did the Trailhead about it but never forced myself to use it on my projects, still looks somehow complex. Similar to Trigger frameworks which are around (Appero, NPSP).

I remember Dreamforce 2017 and great presentation about the internals of Salesforce, but I completely missed the Salesforce Engineering blog. Also have you read the Twelve-Factor App? And do you follow that approach?

Feature branch naming – in big teams include your name in it, also include Work ID and description. Again, I fight about this, the requirement on project is to only use ID and I complain that it is completely meaningless to me and just a short description would be easier than constantly check the requirements to see what was that branch about.

Preserving Git history when migrating to DX – delete the original file at the same time as you commit the new one, Git will take it as rename and preserve the history. Probably make sense to do it in smaller batches not to confuse Git with many changes at once.

Branching strategy, all those Trunk-Based, GitHub Flow, GitLab Flow, Gitflow, Feature Branch, Forking Workflow, … jesus, cannot here be one best practice I can just follow? Freedom and control, pull requests and all these things. Also – delete feature branch after merge or leave it? What are the pros and cons? And finally based on some analysis they found that teams with no approval process or just a peer review achieved higher delivery performance (no surprise) but also a strict process had negative colleration with lead time, deployment frequency, restore time and no correlation with change fail rate.

I wonder whether having Circle Of Success on this topic and sharing different approaches and lessons learned might be useful and any real outcome.

Code reviews also transform development from an isolated activity into a social and collaborative activity.

Code reviews provide a way to transfer knowledge organically throughout a team and so avoid knowledge getting overconcentrated in one person. They lead to standardisation and improved code quality, as well as deep camaraderie between those involved.

Do you really have continuous integration? Jez Humble has three simple questions:

  1. Does your entire team merge their work into a common trunk at least daily?
  2. Does every change to that codebase trigger a comprehensive set of tests to run?
  3. If the build breaks, is it always fixes in less than 10 minutes?

If you cannot answer Yes to those three questions, you are not actually practising continuous integration.

Programmers' Hardest Tasks - naming

This graph always make me smile when I remember the Winter ’20 setting called „enableDisableParallelApexTesting“.

Testing is also part of DevOps, I didn’t know there are so many different tests. What I like about Andrew’s approach is the push for automated tests so testers don’t waste their time again and again on manually testing everything. I know how much work it is (or used to be) to prepare such tests, wonder how other (consulting companies) do it. Also – do you have Test Suits, which you run regularly/do you run all tests regularly/you don’t run them as long as possible?

I love that the book mention things which didn’t connect with DevOps to me – Linting, Static Analysis, Unit Tests (also for UI), Security Analysis. And he also mentions tools – Clayton, SonarQube, CodeScan, ApexPMD (hey, I know that guy!), Codacy, CodeClimate, CheckMarx, Micro Focus Fortify.

A surprising number of Salesforce developers are uneducated about the capabilities of change sets and the Metadata API and may rely on manually recreating configuration to „deploy“ functionality that could easily be automated. Even very senior Salesforce developers may be hanging on to the outdated view that „much“ or „most“ configuration can’t be automatically deployed.

Bookmark Metadata Coverage and check! Those who cannot be deployed via Metadata might be deployable with AutoRABIT or Copado, which are able to configure it with „UI test automation tool“, meaning you just need to record where to click and what to enter.

Which tools to use for deployment?

  • CumulusCI
  • SFDX-Falcon
  • Force-dev-tool
  • The Salesforce Toolkit
  • Appirio DX
  • AutoRABIT
  • Blue Canvas
  • ClickDeploy
  • Copado
  • Flosum
  • Gearset
  • Metazoa Snapshot
  • Hutte.io (hey, CzechDreamin sponsor!)

An Admin’s Guide to Doing DevOps is the final part of the book and we really need to make admins to understand it isn’t something scary. Writing code is just writing, once some setup the process and tool it shouldn’t be that hard for you to adopt it.

A common adage is that DevOps tools are far less important than the culture shift involved. What matters is that everyone whose work impacts your production or is able to collaborate on common systems and that there is a shared sense of resposibility for enabling innovation and reducing risk and confusion.

Deployment errors, merge conflicts, tests – they all may be hard at the beginning but once you get over it you are good.

And the same is with this book, I don’t think it is only for DevOps people or for developers. I think that every consultant and admin should read it as well, think about it, get part of it into their daily routine. Because it will make the whole thing easier in the long term.

As with Benioff’s book I’m sharing this book with Czech community, let me know if you want to read it, I’m happy to share. Because it is worth sharing and reading.

1 komentáře

  1. You basically just summarized the whole book in one blog post, I’m totally impressed! I’m so happy you got through the book, and really grateful to see you sharing it. I’m glad you seemed to like it.

Leave a Reply