Content Comparison

...

Overview

This document contains information on how we will be managing our DevOps process for University of Sydney. This is applicable to all Salesforce deployments across multiple project streams.

...

• Create a branch (follow the process mentioned above)

  • the most common place on where you create the branch from is the feature/* branch. This represents the central dev org of your project

    • e.g. feature/hogwartsavengers represents all the contents inside the .spendplanavengers (Dev) org

• Name the branch similar to the Jira ticket. This is important because the automations on the pipeline would not work if you named your branch differently. For reference:

  • Hogwarts: HOG-xxxx

  • Single CRM: SINGLE-xxxx

  • Wellness: WCE-xxxx

  • Avengers: AVE-xxxx

  • Other - follow the steps here to define a project Adding new project to CICD pipelines

• Before starting development, you can pull the latest changes from org via:

  • sfdx:force:source:pull , although this cannot be used if the sandbox is created prior to us enabling source tracking in PROD

  • or sfdx force:source:retrieve although when using -p you won’t get the new ones created.

  • alternatively, you can use this script to retrieve from package dev-tools-scripts\oft-init-orgRefresh.sh -u <your-org-alias> -k manifest/package.xml , in which you can change the content of the package.xml if you like to exclude items or be specific on the retrieval

    • org alias is the alias of your authorised org in where you want to get the latest updates from

    • 

• Perform your build as per usual either from VSCode or directly on your sandbox

  • if your change is done directly on your sandbox, you have to perform another pull dev-tools-scripts\oft-init-orgRefresh.sh -u <your-org-alias> -k manifest/package.xml

    • Note: you can change the manifest/package.xml if you know specifically what you have changed.

• Commit and stage all changes. you will see all the changes here

  • 

• push to remote

• create pull request (PR) to feature/* (or to sit, uat, or master depending on what you are working on). In a PR, we can code review, comment on it, request changes, decline, or approve.

  • 

• Upon PR, as part of pipeline, it will automatically do the following:

  • compare the branch you created against the destination org, and then run all local tests

    • This does not deploy your changes, it just validates the package into the org

  • The package to validate is the delta of the changes, which means it will not include all metadata, it will only deploy the difference between the two branches.

  • You can check the printed package.xml to be deployed on the pipeline by clicking on the cat ./manifest/package/package.xml entry on the “Validating against destination org” step

    • Image RemovedImage Added

  • if branch name starts with bugfix/ (branched from uat), it will automatically create 1 more pull request to sit IF the validation is successful

    • 

  • if branch name starts with hotfix/ (branched from master), it will automatically create 2 more pull requests to sit and uat IF the validation is successful

• once the pipeline is successful, approvers/requester can merge finally to destination.

  • pipeline will automatically get all the delta and deploy the changes into the destination after merging

• if the pipeline fails, you can check the deployment status on the org, you can correct them by updating the branch to fix the changes and the Pull request will automatically rerun the validation

  • 

...

• If there are instances where only your project wanted to go to PROD, you would need to create a release/ branch

  • this ensures that only those items that you want to deploy (i.e. only the files that your team created) were deployed to PROD

• branch out of master and name it as release/xxxxx (replace xxxxx with an identifier e.g. release/SPM_Release2)

• update the .forceignore file with the files that you don’t want to include to your release. These are the files that are not part of the feature you wanted to release to PROD

  • Image RemovedImage Added

• check out the newly created release/xxxxx branch and then merge uat into this branch

  • Most of the time, this will cause merge conflicts. Fix conflicts accordingly

  • you will still see the ignored files. That’s okay because when the package is validated, all the files you put on .forceignore will be ignored

• once conflicts are resolved, push this to remote and do a Pull Request between the release branch and the master

• You can check the package to be deployed listed as a manifest on the Pull Request by clicking the cat ./manifest/package/package.xml section

  • Image RemovedImage Added

• You can also download the logs so you can copy the manifest and confirm the items that you are about to deploy before you commit

  • Image RemovedImage Added

• approve and merge as per normal

...