Merge

README.md

@@ -6,11 +6,8 @@ For detailed information, please refer to [README-dev.md](README-dev.md).
 
 ## Github Workflows
 
-<<<<<<< HEAD
 To enable automatic deployments during application lifecycle, this repository implements the following Github Workflows:
 
-=======
->>>>>>> b7d8470 (Initialize develop)
 ### Branch develop - on pull request (`.github/workflows/developOnPR.yml`)
 
 This workflow is triggered when Pull Requests are opened against the develop branch. Typically, this occurs when a developer completes their development work and intends to integrate it with the rest of the team. The workflow deploys the content of the source branch, as specified in `manifest/buildfile.json` and related manifest files, to the `build` environment.
@@ -27,11 +24,7 @@ In the case of parallel releases, one job like this is required per team.
 
 This workflow is manually triggered by the release manager. It receives the following input parameters:
 
-<<<<<<< HEAD
 - Git ref: The git reference for creating the release. In Gitflow, this is typically a release branch.
-=======
-- Git ref: The git reference to be used for creating the release. In Gitflow, this is typically a release branch.
->>>>>>> b7d8470 (Initialize develop)
 - Tag: The name of the tag that will be used to tag the reference and create the release and release artifact. For example, `v1.0.0`.
 - Environment: The name of the environment where the build will be tested before generating the release. Typically, this will be a `relbuild` environment.
 
@@ -56,35 +49,22 @@ The workflow downloads the release artifact and deploys it to the target environ
 
 ## Github Repository Secrets
 
-<<<<<<< HEAD
 You need to configure two [repository secrets](https://docs.github.com/en/actions/security-guides/encrypted-secrets#creating-encrypted-secrets-for-a-repository):
-=======
-You need to configure two [environment secrets](https://docs.github.com/en/actions/security-guides/encrypted-secrets#creating-encrypted-secrets-for-a-repository):
->>>>>>> b7d8470 (Initialize develop)
 
 - `JWT_KEY_NONPROD`: This secret should contain the content of a private key used to sign the self-signed certificate required for the connected app in the target environments. Please refer to [this article](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_auth_jwt_flow.htm) for more information. It is recommended to use the same self-signed certificate for all sandboxes in the pipeline.
 - `SVC_CLI_BOT_GITHUB_TOKEN`: This secret should contain a Personal Access Token from the repository's admin account. It allows the Github runner to connect to Github and perform operations such as tag and release creation. Follow [this reference](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens#personal-access-tokens-classic) to create a personal access token and then add it as a repository secret.
 
 ## Environments
 
-<<<<<<< HEAD
 By utilizing [Github environments](https://docs.github.com/en/actions/deployment/targeting-different-environments/using-environments-for-deployment#about-environments), you can easily segregate environment variables and track which version is deployed in each environment.
 
 Developer environments are unmanaged, meaning the CI solution never directly interacts with them.
 
 This repository's workflows interact with three different environments:
-=======
-By utilizing [Github environments](https://docs.github.com/en/actions/deployment/targeting-different-environments/using-environments-for-deployment#about-environments), you can easily segregate environment variables.
-
-Developer environments are unmanaged environments, which means the CI solution never directly interacts with them.
-
-This repository's workflows interact to three different environments:
->>>>>>> b7d8470 (Initialize develop)
 
 - `build`: This environment is used by the `./github/workflows/developOnPR.yml` workflow to validate developers' pull requests before merging them into the integration branch (usually develop).
 - `qa`: This environment is used by the `./github/workflows/developOnPush.yml` workflow to deploy a package that's being worked by the team so functional tests can be executed.
 
-<<<<<<< HEAD
 If your project follows plain Gitflow, these environments are sufficient. However, if you are running parallel releases, you will need a pair of `build`/`qa` environments for each team.
 
 In addition to the team environments, the workflows also refer to release environmentd:
@@ -93,15 +73,6 @@ In addition to the team environments, the workflows also refer to release enviro
 - `uat` and `preprod`: These environments are not linked with a branch and can be used by `./github/workflows/releaseDeploy.yml` workflow as a target environment for a release artifact.
 
 You may need to define other managed environments that can receive release artifacts, such as `sit` or a second `uat`. Once these environments are defined, you can use the `./github/workflows/releaseDeploy.yml` job to deploy artifacts to these environments.
-=======
-If your project follows plain Gitflow, these two environments are sufficient. However, if you are running parallel releases, you will need a pair of build/qa environments for each team.
-
-In addition to the team environments, the workflows also refer to a release environment:
-
-- `relbuild`: This environment is used by the `./github/workflows/releaseCreateOnPushTag.yml` workflow to validate a release deploy before generating the release artifact.
-
-You may need to define additional managed environments that can receive release artifacts, such as `sit`, `uat`, and `stage`. Once these environments are defined, you can use the `./github/workflows/releaseDeploy.yml` job to deploy artifacts to these environments.
->>>>>>> b7d8470 (Initialize develop)
 
 For each environment, you must define the following [environment variables](https://docs.github.com/en/actions/deployment/targeting-different-environments/using-environments-for-deployment#environment-variables):