2

We follow hybrid agile methodology in our project where we have Main release at every month end.

We also have Fast track release on First Week of every month. Purpose of Fast Track release is to make sure that any components which is not approved in Main Release but got an approval later after main release week can be consider for Fast Track release.

Sometimes we also have hotfixes if in case any changes that we deployed does not work as expected then we provide immediate fix and deploy it to production.

Strategy for Main Release:

We are currently using bitbucket pipeline in our project. We are team of 4 developers. We use below strategy in our project for CI/CD for Main release:

enter image description here

Strategy for Fast Track Release:

Currently we don't use CICD for Fast Track release. We add components to ChangeSet & Deploy to Production. But I am planning to use CICD approach for Fast Track Release by creating Separate branches as below(Similar to Main Release branch) :

enter image description here

Strategy for Hotfixes:

Currently we don't have any such strategy for Hotfixes. We normally make changes in DEV/ UAT Org directly and deploy it to production using ChangeSet. We also sync the same changes to other sandboxes in order to sync components . I would like to know what would be the best strategy for Hotfixes using CICD? I am not sure if its ideal to create similar branches that I am using for Main Release for HotFix.

Important Question:

Currently we don't have any rollback plan for release. During Deployment week, we take metadata backup of Production and if in case we want to rollback then we use changeset to rollback to previous state(By adding previous version in UAT from production metadata backup and then deploy using CS). As far as I know we don't have any Real time rollback in Salesforce where by clicking on button, we rollback changes. We can rollback it on Branch but not sure if after changes are committed if there's any way to rollback it automatically. I would like to hear expert suggestion on Rollback Strategy and how we can make it automated using bitbucket. If there's any sample of bitbucket yml file, it would be helpful.

I would also like to know if the present strategy that we're using for Main Release if we can improve it better. Any suggestions for improved branching Strategy would be helpful!

2
  • 1
    It might be best to focus the question to one thing (ex. questions about workflow/branch process or how to implement a rollback). What have you looked into or what are you unsure about? In terms of "suggestions", have you taken a look at branching patterns. Hotfixes or anything that needs to get deployed quicker can just be a new branch that gets merged into the main branch. Jan 5, 2022 at 22:11
  • @KrisGoncalves I am unsure about CICD process that we're currently using whether its recommended approach or not or should we create our personal org , make changes and then push to actual developer org instead of doing direct development in DEV org? About Rollback mechanism, I am not sure what would be best way to achieve rollback in bitbucket as I never worked on CICD project earlier. What I am looking for is the best strategy that I can use for Main Release, Fast Track Release and Hotfixes and if I have rollback in any of these case then what would be the rollback mechanism?
    – SFDCDJ
    Jan 6, 2022 at 6:43

1 Answer 1

6

We can't answer what your best branching strategy would be. We don't know enough and that questions covers a lot of areas (git, branching, sfdx, deployments, metadata, etc). Likewise, it's highly specific to

  • Your team members roles (ex. 4 developers and 12 admins)
  • Your members' expertise - familiarity with git, branching, etc.
  • Your org - lots of customization/metadata, less, etc
  • What your releases typically look like (ex. big changes, small changes)

The best strategy is the one that works for your team. However, what is a bit more objective is "not so good" strategies or pitfalls:

  • Sharing a static, developer org across your developers that they all work in
  • Not using source control as the source of truth (ex. deploying through change set)
  • Having changes that don't follow the same process as other changes
  • Not having commitment from team members to learn any new tools or processes.
  • Not having a plan/process outlined for disaster (ex. rollback scenario)
  • Not having changes peer reviewed in pull requests.

Likewise, there's some things you can look into when talking about revamping or starting your CI/CD process


The rest of the answer below is generic and hopefully helpful to get more knowledge to make decisions and, above all, avoid some of the pitfalls above

Branching Strategy

There's many branching patterns and I'd stress what's more important is getting comfortable understanding what you'll do rather than worry whether it's the best or perfect. You can keep it simple in the beginning if it's new and iterate on it as you re-evaluate once you're more familiar with the tools/process or failures you may have encountered. Otherwise, it can be as simple as a main branch with branches off of it as needed:

  • Main branch - your production code
    • Monthly release branch
      • Developer specific feature branch
    • Fast track branch (as needed)
    • Hotfix branch (as needed)

Every month, monthly release branch merges into main. However, nothing is stopping new branches from being created as needed (hotfix) and merging into main beforehand. You'd then merge what's in main back into the monthly branch. You can add more branches in between main so that you can control when changes hit certain orgs (ex. staging branch, dev branch, etc) so it'd be a branch per environment.

Orgs

This can depend on what you have access to (ex. full, partial, etc) and your testing strategy/complexity. Typically, you'd have a staging org - the changes to be verified before a release. After that - you could have different orgs to suit various needs (ex. Integration testing, different QA orgs, a "dev" org) or provide different junctures in your process.

As an example, a staging/release branch off of main would give you control over when things go into your staging org - this would allow your fast track or hotfix to go into staging clean and get tested without the monthly release yet being there even though you may have an org earlier in the process that does have your monthly release being tested in it (that would also have the hotfix). This helps you avoid having to do so many backfills across orgs as the changes hit them in an ordered fashion so, at the end, the changes went through all the pre-req orgs before going into staging, getting tested, and hitting production.

"shared" orgs

The key point is to move away from sharing a dev org across your developers. It's a mess for developers, for getting the latest changes backfilled, and for verifying changes. Scratch orgs should be something you look into - it might not meet your need depending on your settings/features, but it allows devs control to always have the latest source and spin up a new org ad hoc without caring about the org as it's not the source. This'll limit the need to backfill automatically at this part of the process (devs have control to git pull and source:push or spin up a new org).

If the issue with moving away from shared dev orgs to do work in is data, I'd suggest looking into spending the time automating data creation (ex. snowfakery) within your scratch org creation process to make those orgs as valuable.

Rollbacks

You want this type of change, a rollback, to be secure and work - you don't want to cause more issues so sometimes automating it isn't the first step. Git/source control is your friend - you have the commits and the ability to revert a single commit, many commits, or even move the branch back in history if you'd like. This makes "rollback" just another branch you quickly create, merge into whatever branch, have it deployed into staging, test it undid the issue, and then merged into production/main branch. I'll also mention that paid solutions would provide this option as well if you need it more automated.

Resources

There's lots of resources, opinions, "best-practices", etc. Sometimes CI/CD tools have some good resources that you can read up on without having to pay for their product. And, as always, there's some good questions on SFSE that cover various parts of this large process

1
  • Thanks Kris for the valuable information.
    – SFDCDJ
    Jan 7, 2022 at 6:06

Not the answer you're looking for? Browse other questions tagged .