diff --git a/decision records/release/001-release.md b/decision records/release/001-release.md index 39415dea0..4edc19eed 100644 --- a/decision records/release/001-release.md +++ b/decision records/release/001-release.md @@ -17,7 +17,7 @@ sfpowerscripts currently does not have a notion of 'release', which some CICD pl Utilises a release definition file (YAML format) and combines the steps in a release into a single SFDX command: fetching artifacts, installing dependencies, deployment and release changelog generation. -This command utilizes a YAML based release defintion as opposed to sfdx-project.json which is used by the orchestrator elsewhere. The benefit of using a seperate defintion is to keep release and build defintions seperated, as one could use for selective deployments. +This command utilizes a YAML based release definition as opposed to sfdx-project.json which is used by the orchestrator elsewhere. The benefit of using a separate definition is to keep release and build definitions separated, as one could use for selective deployments. Pros: * Easy to use @@ -40,7 +40,7 @@ Cons: * Unintuitive to use, requires external documentation -## Decision +## Decision Chosen option: 1. `orchestrator:release` command diff --git a/decision records/release/003-release-autorollback.md b/decision records/release/003-release-autorollback.md index 0cb6cd2f1..11037c7fb 100644 --- a/decision records/release/003-release-autorollback.md +++ b/decision records/release/003-release-autorollback.md @@ -10,23 +10,23 @@ Issue: [Issue #478](https://github.com/flxbl-io/sfp/issues/478) +## Consequences -This functionality will support ability to rollback an org to an earlier release. However not every rollbacks in Salesforce is going to be successfull, as the platform doesn't inherently support the notion of a rollback for many components and its tightly based on dependencies of a particular component. This rollback functionality could also leave the org with items that are not removed +This functionality will support ability to rollback an org to an earlier release. However not every rollbacks in Salesforce is going to be successful, as the platform doesn't inherently support the notion of a rollback for many components and its tightly based on dependencies of a particular component. This rollback functionality could also leave the org with items that are not removed diff --git a/decision records/release/006-release-defn-generator.md b/decision records/release/006-release-defn-generator.md index ebbdc5662..57c5f2cef 100644 --- a/decision records/release/006-release-defn-generator.md +++ b/decision records/release/006-release-defn-generator.md @@ -10,7 +10,7 @@ sfpowerscripts allow a release manager to utilize 'LATEST_GIT_TAG' or to use 'S ## Decision -sfpowerscripts will introduce a new command 'releasedefinition:generate' that can be used to generate a release definition file, The generatated release definiton can then be used as an input to 'orchestrator:release' to deploy artifacts in the pipeline. +sfpowerscripts will introduce a new command 'releasedefinition:generate' that can be used to generate a release definition file, The generatated release definition can then be used as an input to 'orchestrator:release' to deploy artifacts in the pipeline. ```mermaid flowchart TD @@ -24,20 +24,20 @@ direction LR B --> E[[release--<<< 3 >>>.yml]] A--pushes tag--->id1 id1[(Git)]--fetches info from tag--> B - + end subgraph ZB["release<< env >>"] direction LR - + F[[release--<<< 2 >>>.yml]]-- 1.Input to command -->G[orchestrator:release < env >] id2[(Git)]--2.Fetches info from tag--> G - id3[(Artifact Repo)]--3.Fetches artifacts--> G + id3[(Artifact Repo)]--3.Fetches artifacts--> G end subgraph ZC["release<< env >>"] direction LR - + F1[[release--<<< 2 >>>.yml]]-- 1.Input to command -->G1[orchestrator:release < env >] id21[(Git)]--2.Fetches info from tag--> G1 id31[(Artifact Repo)]--3.Fetches artifacts--> G1 @@ -46,7 +46,7 @@ end ZA -.on demand.-> ZB-.followed by.->ZC ``` -The command need a mechanism to figure out versions of articats that constitute a release. This can be either done by utilizing an org as a reference or pointing to a particular commit reference. +The command need a mechanism to figure out versions of articats that constitute a release. This can be either done by utilizing an org as a reference or pointing to a particular commit reference. The mechanism of using Org as a source of truth, was discarded due to the following reasons: @@ -54,7 +54,7 @@ The mechanism of using Org as a source of truth, was discarded due to the follow * Strong dependency on an org in the pipeline is against the guidelines in DX@Scale principles, as any org could be refreshed at any point in time. * An org could be installed with artifacts created from 'quick build' stage. However these artifacts are typically not published in to the artifacts repositoy -However, using tags on the version control closely matches the existing behaviour of the release command with 'LATEST_GIT_TAG', but provide additional traceability by providing the user ability to generate and store the release defintions in version control. These versioned release defintions then could be used on demand at any point in time. +However, using tags on the version control closely matches the existing behaviour of the release command with 'LATEST_GIT_TAG', but provide additional traceability by providing the user ability to generate and store the release definitions in version control. These versioned release definitions then could be used on demand at any point in time. The command will utilize a schema to generate the release definition. This allows the user for flexibility in terms of selecting artifacts @@ -81,10 +81,10 @@ excludeArtifactsWithTag: # Exclude the following package dependecies from the generated definition excludePackageDependencies: - Pkg1 -# set below properties in generated release definition +# set below properties in generated release definition baselineOrg: << org >> promotePackagesBeforeDeploymentToOrg: << org >> -skipIfAlreadyInstalled: <> +skipIfAlreadyInstalled: <> changelog: workItemFilters: - <> @@ -97,8 +97,8 @@ changelog: ***Implementation notes*** 1. The command should expect the name of the release as an input. The passed in name will be substituted in the generated release file -2. The command is expectected to be used from any stage in the repository +2. The command is expected to be used from any stage in the repository 3. The input definition to this file will be called as *release definition config* 4. Packages defined in sfdx-project.json will be filtered by the inputs in release definition config 5. IncludeOnly or ExcludeArtifacts are mutually exclusive, with include taking precedence over exclude -6. PackageDependencies are picked from the packageAliases +6. PackageDependencies are picked from the packageAliases diff --git a/packages/sfp-cli/command-docs/changelog.md b/packages/sfp-cli/command-docs/changelog.md index e634d5a96..19aa96647 100644 --- a/packages/sfp-cli/command-docs/changelog.md +++ b/packages/sfp-cli/command-docs/changelog.md @@ -21,7 +21,7 @@ FLAGS -n, --releasename= (required) Name of the release for which to generate changelog -w, --workitemfilter= (required) Regular expression used to search for work items (user stories) introduced in release - --directory= Relative path to directory to which the release defintion file should be generated, if + --directory= Relative path to directory to which the release definition file should be generated, if the directory doesnt exist, it will be created --limit= limit the number of releases to display in changelog markdown --loglevel=