Content Comparison

...

• 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

  • 

• 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

Note: Few points to keep in mind for pushing your metadata to the feature branch are:

• Always commit the components related to the ticket only corresponding to the ticket branch.

• Always name the branch corresponding to the ticket number i.e AVE-**.

• Always put appropriate commit messages so that person reviewing the pull request knows what is this about.

• Check the pipeline if the pull request build is failed and if issues can be fixed.