From 7fe0d843fbee5ce658dcec03ea27998d926637ee Mon Sep 17 00:00:00 2001 From: Ralph Bean Date: Sun, 5 Nov 2023 12:12:46 -0500 Subject: [PATCH 01/15] Initial draft of decoupling deployment ADR --- ADR/0032-decoupling-deployment.md | 176 ++++++++++++++++++++++++++++++ 1 file changed, 176 insertions(+) create mode 100644 ADR/0032-decoupling-deployment.md diff --git a/ADR/0032-decoupling-deployment.md b/ADR/0032-decoupling-deployment.md new file mode 100644 index 00000000..5c570928 --- /dev/null +++ b/ADR/0032-decoupling-deployment.md @@ -0,0 +1,176 @@ +# 32. Decoupling Deployment + +Date: 2023-11-17 + +## Status + +Draft + +## Authors + +* Ralph Bean + +## Context + +Since the beginning of our project, we've had an emphasis on providing an integrated experience for +the user, automating all steps through build, test, deployment, and release to higher environments. + +Some challenges: + +- Our controllers' APIs are highly coupled. For example, it isn't feasible to try and use + [integration-service] today without [application-service] and [gitops-service]. This creates + a high barrier to engage with some of the useful subsystems we've built. A user (and potential + contributor) has to adopt the whole thing, or nothing. +- Today, we can generate simple but often incorrect deployment manifests for users' applications, + which we deploy via the application gitops repo. The user cannot interact with or influence these + resources directly; they have to do so through the Application/Component API. If we permit them to + directly provide deployment resources through that API, the API will become a leaky abstraction. + If don't permit them to provide their own resources, and instead try to handle every application + configuration case in the HAS generation code, we will struggle to keep up with users' demands for + the many and varied kinds of application deployments. + +See also [RHTAP-1873](https://issues.redhat.com/browse/RHTAP-1873). + +## Decision + +We are going to decouple the deployment from the build, test, and release portions of our system. + +**Deployment**: + +- The [Environment], [SnapshotEnvironmentBinding], and [GitOpsDeploymentManagedEnvironment] + resources will be deprecated and eventually decomissioned. +- The [application-service] will stop generating GitOps repo content. +- HAC will stop rendering [Environments] and their status. +- If a user wants to make use of deployment capabilities, we will promote the usage of [renovatebot] + to propagate _released_ images to their self-managed gitops repo as pull requests. + +**Test and promotion**: + +- We will retain the [DeploymentTargetClaim], [DeploymentTarget], and [DeploymentTargetClass] APIs. + Collectively, call these the "DTC" APIs. These should have no dependence on other AppStudio APIs. + Only [integration-service] should depend on them. The controllers that support the DTC API should + be organized into their own project: "the [deployment-target-operator]", or something like that. +- [integration-service] should be modified to create and destroy [DeploymentTargetClaims] directly + instead of [Environment] resources. Users will be expected to provide integration test pipelines + that accept a kubeconfig and snapshot as they do now, but those pipelines should now take initial + steps to *deploy the instance of their application to be tested* to the deployment target provided + by [integration-service] using the provided kubeconfig. +- We should promote [release-service] as the primary means to advertise to [renovatebot] that one or + more images have passed testing and are ready to be promoted to a particular environment (with + a lowercase "e") by way of image tags in a registry. + +### Out of scope + +Some other interesting ideas that are floating around these days, but which should be taken up in +other ADRs, if we take them up at all: + +- Decoupling [integration-service] and [release-service] from a shared [Snapshot] API. They will + continue to share a [Snapshot] API as of this ADR. +- Decoupling [integration-service] from the [application-service] APIs. It will still promote images + to the "global candidate list" and continue to use the list of [Components] to guide its + construction of [Snapshots]. + +### Use Case Descriptions + +**During onboarding**: whereas today when a user requests a new appstudio tier namespace, the tier +template includes an [Environment] that the integration-service will promote to. Tomorrow, the +appstudio tier template should no longer include an [Environment] which on its own will cause +integration-service to _not_ trigger a deployment when testing completes. Instead, the appstudio +tier template should include a [ReleasePlan] with a reference to the [push-to-external-registry] +release pipeline. This new default [ReleasePlan] should carry parameters such that whenever +a [Snapshot] is successfully tested, a [Release] is created that re-tags the images in their same +quay repositories with a tag like `:released` or `:validated` (name tbd). The +[push-to-external-registry] pipeline can use the `appstudio-pipeline` service account in the user's +dev workspace, which already has push access to the repository in question. + +```mermaid +flowchart TD + NSTierTemplate --> |provides| ReleasePlan + A[fa:fa-code-commit Git Commit] --> |webhook| PipelinesAsCode + PipelinesAsCode --> |creates| build[Build PipelineRun] + build --> |triggers| integration-service + integration-service --> |asks| decision{Is there a ReleasePlan?} + ReleasePlan --> |influences| decision + decision --> |yes| Release + build --> |pushes the image| quay.io/redhat-user-workloads/tenant/component + Release --> |tags the image for release| quay.io/redhat-user-workloads/tenant/component + quay.io/redhat-user-workloads/tenant/component --> renovatebot[User provided RenovateBot] + renovatebot --> |updates| gitops-repo[User provided GitOps repo] + gitops-repo --> |causes deployment via| argocd[User provided ArgoCD] + argocd --> |deploys to| cluster[User provided cluster] +``` + +Outside of the AppStudio member cluster, the user is responsible for acquiring a gitops repo and +deployment environments of their choice, manually laying out their application resources in the repo +(assisted by tools like `kam`), specifying image references by tag to match the `:released` or +`:validated` tagging schem mentioned above, configuring Argo to deploy from their gitops repo, and +configuring [renovatebot] to propagate image updates by digest to their gitops repo. + +**For manual creation of new environments** - the user manages this directly using a combination of +their gitops repo and argo, outside of the AppStudio member cluster. + +**For automated testing in ephemeral environments** - the user specifies an +[IntegrationTestScenario] CR with a [DeploymentTargetClass] reference. After a build completes, but +before it executes tests, the integration-service creates a new [DeploymentTargetClaim] CR with +a [DTCLS] matching the one on the [IntegrationTestScenario]. This should cause the +[deployment-target-operator] to provision and bind a [DeploymentTarget] matching the +[DeploymentTargetClass]. [integration-service] then passes the kubeconfig and [Snapshot] to the +integration test to deploy the user's app and run tests. The integration-service should delete the +[DTC] once it isn’t needed anymore for the test. + +```mermaid +flowchart TD + User --> |provides| IntegrationTestScenario + IntegrationTestScenario --> |references| DeploymentTargetClass + commit[fa:fa-code-commit Git Commit] --> |webhook| PipelinesAsCode + PipelinesAsCode --> |creates| build[Build PipelineRun] + build --> |triggers| integration-service + integration-service --> |consults| IntegrationTestScenario + integration-service --> |creates| DeploymentTargetClaim + DeploymentTargetClaim --> |references| DeploymentTargetClass + DeploymentTargetClaim --> |is bound to| DeploymentTarget + DeploymentTarget --> |is associated with| kubeconfig[kubeconfig Secret] + kubeconfig --> |is provided to| test + integration-service --> |creates| test[Test PipelineRun] + DeploymentTarget --> |represents| cluster + test --> |deploys user app to| cluster + test --> |executes tests against| cluster +``` + +## Consequences + +- Users who expect effortless deployment of their app when onboarding to the system will be + dissapointed. They have more work to do to set up a deployment of their app outside the system. +- Users will lose visibility of their applications' deployments and status in the AppStudio UI + (HAC). Other systems like the Argo UI are arguably better at this than we are. +- Users who expect to provide and manage their own resources to control their app will be delighted. + They now no longer have to interact with an intermediary API to try to express details about their + deployment(s). +- As a team, we'll be in a position to try to achieve independence for the [DeploymentTarget] APIs, + make it usable outside the context of AppStudio, and ideally make it attractive for collaborators. + +## Phases of implementation + +- Create the [deployment-target-operator], as step 0. +- [integration-service]: use [DTCs] directly instead of [Environments]. +- [release-service]: Drop the environment reference from the [ReleasePlanAdmission] spec, and + related controller code for managing a [SnapshotEnvironmentBinding]. +- [HAC]: update [IntegrationTestScenario] CRUD to use [DTCs] instead of [Environments]. +- [HAC]: Drop UI features showing the [Environments]: (commit view, Environments pane, etc.) +- [integration-service]: stop creating a [SEB] for the lowest [Environments]. +- [application-service]: stop generating the gitops repo content in response to [SEBs]. +- Drop the [Environment], [SnapshotEnvironmentBinding], and [GitOpsDeploymentManagedEnvironment] + APIs from the [application-api] repo. + +[Environment]: ../ref/application-environment-api.md#environment +[Environments]: ../ref/application-environment-api.md#environment +[DT]: ../ref/application-environment-api.md#deploymenttarget +[DTs]: ../ref/application-environment-api.md#deploymenttarget +[DeploymentTarget]: ../ref/application-environment-api.md#deploymenttarget +[DeploymentTargets]: ../ref/application-environment-api.md#deploymenttarget +[DTC]: ../ref/application-environment-api.md#deploymenttargetclaim +[DTCs]: ../ref/application-environment-api.md#deploymenttargetclaim +[DeploymentTargetClaim]: ../ref/application-environment-api.md#deploymenttargetclaim +[DeploymentTargetClaims]: ../ref/application-environment-api.md#deploymenttargetclaim +[DeploymentTargetClass]: ../ref/application-environment-api.md#deploymenttargetclass +[DeploymentTargetClasses]: ../ref/application-environment-api.md#deploymenttargetclass From 365830ad7948ed778abafc441fe1ada750d01f76 Mon Sep 17 00:00:00 2001 From: Ralph Bean Date: Mon, 20 Nov 2023 13:28:26 -0500 Subject: [PATCH 02/15] Align list style --- ADR/0032-decoupling-deployment.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ADR/0032-decoupling-deployment.md b/ADR/0032-decoupling-deployment.md index 5c570928..e56e0cdc 100644 --- a/ADR/0032-decoupling-deployment.md +++ b/ADR/0032-decoupling-deployment.md @@ -8,7 +8,7 @@ Draft ## Authors -* Ralph Bean +- Ralph Bean ## Context From 4166830b8a35f0f227ea7f5ddcc4ed81cd3a3045 Mon Sep 17 00:00:00 2001 From: Ralph Bean Date: Mon, 20 Nov 2023 13:28:39 -0500 Subject: [PATCH 03/15] Supply missing links --- ADR/0032-decoupling-deployment.md | 29 +++++++++++++++++++++++++++-- 1 file changed, 27 insertions(+), 2 deletions(-) diff --git a/ADR/0032-decoupling-deployment.md b/ADR/0032-decoupling-deployment.md index e56e0cdc..b2bea4a8 100644 --- a/ADR/0032-decoupling-deployment.md +++ b/ADR/0032-decoupling-deployment.md @@ -76,11 +76,11 @@ other ADRs, if we take them up at all: template includes an [Environment] that the integration-service will promote to. Tomorrow, the appstudio tier template should no longer include an [Environment] which on its own will cause integration-service to _not_ trigger a deployment when testing completes. Instead, the appstudio -tier template should include a [ReleasePlan] with a reference to the [push-to-external-registry] +tier template should include a [ReleasePlan] with a reference to the [push-to-registry] release pipeline. This new default [ReleasePlan] should carry parameters such that whenever a [Snapshot] is successfully tested, a [Release] is created that re-tags the images in their same quay repositories with a tag like `:released` or `:validated` (name tbd). The -[push-to-external-registry] pipeline can use the `appstudio-pipeline` service account in the user's +[push-to-registry] pipeline can use the `appstudio-pipeline` service account in the user's dev workspace, which already has push access to the repository in question. ```mermaid @@ -162,8 +162,31 @@ flowchart TD - Drop the [Environment], [SnapshotEnvironmentBinding], and [GitOpsDeploymentManagedEnvironment] APIs from the [application-api] repo. +[renovatebot]: https://github.com/renovatebot/renovate +[deployment-target-operator]: # +[gitops-service]: ../ref/gitops-service.md +[push-to-registry]: https://github.com/redhat-appstudio/release-service-catalog/tree/main/pipelines/push-to-external-registry +[application-api]: https://github.com/redhat-appstudio/application-api +[integration-service]: ../book/integration-service.md +[release-service]: ../book/release-service.md +[Component]: ../ref/application-environment-api.md#component +[Components]: ../ref/application-environment-api.md#component [Environment]: ../ref/application-environment-api.md#environment [Environments]: ../ref/application-environment-api.md#environment +[GitOpsDeploymentManagedEnvironment]: ../ref/application-environment-api.md#GitOpsDeploymentManagedEnvironment +[GitOpsDeploymentManagedEnvironments]: ../ref/application-environment-api.md#GitOpsDeploymentManagedEnvironment +[SnapshotEnvironmentBinding]: ../ref/application-environment-api.md#snapshotenvironmentbinding +[SnapshotEnvironmentBindings]: ../ref/application-environment-api.md#snapshotenvironmentbinding +[Snapshot]: ../ref/application-environment-api.md#snapshot +[Snapshots]: ../ref/application-environment-api.md#snapshot +[Release]: ../ref/release-service.md#Release +[Releases]: ../ref/release-service.md#Release +[ReleasePlan]: ../ref/release-service.md#ReleasePlan +[ReleasePlans]: ../ref/release-service.md#ReleasePlan +[ReleasePlanAdmission]: ../ref/release-service.md#ReleasePlanAdmission +[ReleasePlanAdmissions]: ../ref/release-service.md#ReleasePlanAdmission +[IntegrationTestScenario]: ../ref/integration-service.md#IntegrationTestScenario +[IntegrationTestScenarios]: ../ref/integration-service.md#IntegrationTestScenario [DT]: ../ref/application-environment-api.md#deploymenttarget [DTs]: ../ref/application-environment-api.md#deploymenttarget [DeploymentTarget]: ../ref/application-environment-api.md#deploymenttarget @@ -172,5 +195,7 @@ flowchart TD [DTCs]: ../ref/application-environment-api.md#deploymenttargetclaim [DeploymentTargetClaim]: ../ref/application-environment-api.md#deploymenttargetclaim [DeploymentTargetClaims]: ../ref/application-environment-api.md#deploymenttargetclaim +[DTCls]: ../ref/application-environment-api.md#deploymenttargetclass +[DTClses]: ../ref/application-environment-api.md#deploymenttargetclass [DeploymentTargetClass]: ../ref/application-environment-api.md#deploymenttargetclass [DeploymentTargetClasses]: ../ref/application-environment-api.md#deploymenttargetclass From 344c8bb9036b17679ac688d8f0fe14e870aa22c3 Mon Sep 17 00:00:00 2001 From: Ralph Bean Date: Thu, 30 Nov 2023 13:34:05 -0500 Subject: [PATCH 04/15] Try to clarify which repo is being talked about --- ADR/0032-decoupling-deployment.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ADR/0032-decoupling-deployment.md b/ADR/0032-decoupling-deployment.md index b2bea4a8..a3e9cb75 100644 --- a/ADR/0032-decoupling-deployment.md +++ b/ADR/0032-decoupling-deployment.md @@ -78,7 +78,7 @@ appstudio tier template should no longer include an [Environment] which on its o integration-service to _not_ trigger a deployment when testing completes. Instead, the appstudio tier template should include a [ReleasePlan] with a reference to the [push-to-registry] release pipeline. This new default [ReleasePlan] should carry parameters such that whenever -a [Snapshot] is successfully tested, a [Release] is created that re-tags the images in their same +a [Snapshot] is successfully tested, a [Release] is created that re-tags the images in build-time quay repositories with a tag like `:released` or `:validated` (name tbd). The [push-to-registry] pipeline can use the `appstudio-pipeline` service account in the user's dev workspace, which already has push access to the repository in question. From 7d6e086feb69ba0344b2e912e45e348c77e0148e Mon Sep 17 00:00:00 2001 From: Ralph Bean Date: Thu, 30 Nov 2023 13:34:13 -0500 Subject: [PATCH 05/15] Explicitly mention which APIs --- ADR/0032-decoupling-deployment.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/ADR/0032-decoupling-deployment.md b/ADR/0032-decoupling-deployment.md index a3e9cb75..ee0a12ac 100644 --- a/ADR/0032-decoupling-deployment.md +++ b/ADR/0032-decoupling-deployment.md @@ -66,9 +66,9 @@ other ADRs, if we take them up at all: - Decoupling [integration-service] and [release-service] from a shared [Snapshot] API. They will continue to share a [Snapshot] API as of this ADR. -- Decoupling [integration-service] from the [application-service] APIs. It will still promote images - to the "global candidate list" and continue to use the list of [Components] to guide its - construction of [Snapshots]. +- Decoupling [integration-service] from the [application-service] APIs, like [Application] and + [Component]. It will still promote images to the "global candidate list" (on the [Component] + resources) and continue to use the list of [Components] to guide its construction of [Snapshots]. ### Use Case Descriptions From 116d4712c9630a5ff41c270d76c3a551012dfa06 Mon Sep 17 00:00:00 2001 From: Ralph Bean Date: Thu, 30 Nov 2023 14:56:20 -0500 Subject: [PATCH 06/15] Link to other ADRs --- ADR/0008-environment-provisioning.md | 2 +- ADR/0014-let-pipelines-proceed.md | 1 + ADR/0016-integration-service-promotion-logic.md | 6 +++--- ADR/0028-handling-snapshotenvironmentbinding-errors.md | 2 +- ADR/0032-decoupling-deployment.md | 8 ++++++++ 5 files changed, 14 insertions(+), 5 deletions(-) diff --git a/ADR/0008-environment-provisioning.md b/ADR/0008-environment-provisioning.md index afcea53c..6775dc4f 100644 --- a/ADR/0008-environment-provisioning.md +++ b/ADR/0008-environment-provisioning.md @@ -4,7 +4,7 @@ Date: 2022-12-14 ## Status -Accepted +Superceded by [ADR 32. Decoupling Deployment](0032-decoupling-deployment.html) ## Approvers diff --git a/ADR/0014-let-pipelines-proceed.md b/ADR/0014-let-pipelines-proceed.md index a2367dcd..a67d8aa7 100644 --- a/ADR/0014-let-pipelines-proceed.md +++ b/ADR/0014-let-pipelines-proceed.md @@ -10,6 +10,7 @@ Accepted Relates to: * [ADR 13. AppStudio Test Stream - API contracts](0013-integration-service-api-contracts.html) * [ADR 30. Tekton Results Naming Convention](0030-tekton-results-naming-convention.html) +* [ADR 32. Decoupling Deployment](0032-decoupling-deployment.html) ## Context diff --git a/ADR/0016-integration-service-promotion-logic.md b/ADR/0016-integration-service-promotion-logic.md index b4a8aeac..3b5c0a3d 100644 --- a/ADR/0016-integration-service-promotion-logic.md +++ b/ADR/0016-integration-service-promotion-logic.md @@ -5,7 +5,7 @@ ## Status -Accepted +Superceded by [ADR 32. Decoupling Deployment](0032-decoupling-deployment.html) ## Context @@ -24,7 +24,7 @@ Note: This functionality has now been completely dropped from the build-service DevOps workflows often automate deployments of applications across different environments to ensure that the workloads are properly tested before being further promoted to an environment with a higher -service level agreement. +service level agreement. The promotion path can be represented with a directed acyclic graph from the environment with the lowest SLA to the one with the highest, for example development -> staging -> production. In AppStudio, this promotion logic would be represented by a set of components (container images) defined by @@ -76,7 +76,7 @@ push (merge-to-main) events gets promoted to lowest environments and released. ## Consequences * As per this decision, Integration Service now holds the full charge to automatically promote the Snapshot of the - Application to the user’s defined lowest environments only. + Application to the user’s defined lowest environments only. The integration service doesn't hold the control to make promotions to the non-lowest/production environments. * Once all the tests succeed the Snapshot will always be deployed via a single code path, in a single service. diff --git a/ADR/0028-handling-snapshotenvironmentbinding-errors.md b/ADR/0028-handling-snapshotenvironmentbinding-errors.md index c1cdcd4f..8e883d1b 100644 --- a/ADR/0028-handling-snapshotenvironmentbinding-errors.md +++ b/ADR/0028-handling-snapshotenvironmentbinding-errors.md @@ -2,7 +2,7 @@ Date: 2023-08-31 ## Status -Accepted +Superceded by [ADR 32. Decoupling Deployment](0032-decoupling-deployment.html) ## Context It is currently not possible to determine whether a SnapshotEnvironmentBinding (SEB) is stuck in an unrecoverable state. This is a major problem when deciding if an ephemeral SEB needs to be cleaned up by the integration service's SnapshotEnvironmentBinding controller. An inability to clean up errored SEBs can overload the cluster. diff --git a/ADR/0032-decoupling-deployment.md b/ADR/0032-decoupling-deployment.md index ee0a12ac..36584999 100644 --- a/ADR/0032-decoupling-deployment.md +++ b/ADR/0032-decoupling-deployment.md @@ -6,6 +6,14 @@ Date: 2023-11-17 Draft +Relates to: +* [ADR 14. Let Pipelines Proceed](0014-let-pipelines-proceed.html) + +Supercedes: +* [ADR 08. Environment Provisioning](0008-environment-provisioning.html) +* [ADR 16. Integration Service Promotion Logic](0016-integration-service-promotion-logic.html) +* [ADR 28. Handling SnapshotEnvironmentBinding Errors](0028-handling-snapshotenvironmentbinding-errors.html) + ## Authors - Ralph Bean From b64a9117a99932a83e9eb3117c38ecbba96ad2fb Mon Sep 17 00:00:00 2001 From: Ralph Bean Date: Thu, 30 Nov 2023 15:03:03 -0500 Subject: [PATCH 07/15] Mention dependabot, for completeness --- ADR/0032-decoupling-deployment.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/ADR/0032-decoupling-deployment.md b/ADR/0032-decoupling-deployment.md index 36584999..7ec194aa 100644 --- a/ADR/0032-decoupling-deployment.md +++ b/ADR/0032-decoupling-deployment.md @@ -50,7 +50,8 @@ We are going to decouple the deployment from the build, test, and release portio - The [application-service] will stop generating GitOps repo content. - HAC will stop rendering [Environments] and their status. - If a user wants to make use of deployment capabilities, we will promote the usage of [renovatebot] - to propagate _released_ images to their self-managed gitops repo as pull requests. + to propagate _released_ images to their self-managed gitops repo as pull requests. Dependabot is + equally viable if the user's gitops repo is on GitHub. **Test and promotion**: From aea3175fa9f2aafb7e62026e941f2036bf5eae12 Mon Sep 17 00:00:00 2001 From: Ralph Bean Date: Thu, 30 Nov 2023 15:03:48 -0500 Subject: [PATCH 08/15] Add missing link --- ADR/0032-decoupling-deployment.md | 1 + 1 file changed, 1 insertion(+) diff --git a/ADR/0032-decoupling-deployment.md b/ADR/0032-decoupling-deployment.md index 7ec194aa..e229943d 100644 --- a/ADR/0032-decoupling-deployment.md +++ b/ADR/0032-decoupling-deployment.md @@ -176,6 +176,7 @@ flowchart TD [gitops-service]: ../ref/gitops-service.md [push-to-registry]: https://github.com/redhat-appstudio/release-service-catalog/tree/main/pipelines/push-to-external-registry [application-api]: https://github.com/redhat-appstudio/application-api +[application-service]: ../book/application-service.md [integration-service]: ../book/integration-service.md [release-service]: ../book/release-service.md [Component]: ../ref/application-environment-api.md#component From 7a8af2ff28d7f6587482b49575d92dcedf09baa1 Mon Sep 17 00:00:00 2001 From: Ralph Bean Date: Tue, 5 Dec 2023 15:58:33 -0500 Subject: [PATCH 09/15] Update for repo name change --- ADR/0032-decoupling-deployment.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/ADR/0032-decoupling-deployment.md b/ADR/0032-decoupling-deployment.md index e229943d..385ca997 100644 --- a/ADR/0032-decoupling-deployment.md +++ b/ADR/0032-decoupling-deployment.md @@ -176,9 +176,9 @@ flowchart TD [gitops-service]: ../ref/gitops-service.md [push-to-registry]: https://github.com/redhat-appstudio/release-service-catalog/tree/main/pipelines/push-to-external-registry [application-api]: https://github.com/redhat-appstudio/application-api -[application-service]: ../book/application-service.md -[integration-service]: ../book/integration-service.md -[release-service]: ../book/release-service.md +[application-service]: ../architecture/application-service.md +[integration-service]: ../architecture/integration-service.md +[release-service]: ../architecture/release-service.md [Component]: ../ref/application-environment-api.md#component [Components]: ../ref/application-environment-api.md#component [Environment]: ../ref/application-environment-api.md#environment From 4b9e5ac1c657f697d941f8d30abd21ddba63ebb1 Mon Sep 17 00:00:00 2001 From: Ralph Bean Date: Tue, 5 Dec 2023 16:34:04 -0500 Subject: [PATCH 10/15] Incorporate feedback from Gal --- ADR/0032-decoupling-deployment.md | 38 +++++++++++++++++++------------ 1 file changed, 23 insertions(+), 15 deletions(-) diff --git a/ADR/0032-decoupling-deployment.md b/ADR/0032-decoupling-deployment.md index 385ca997..6b678ba8 100644 --- a/ADR/0032-decoupling-deployment.md +++ b/ADR/0032-decoupling-deployment.md @@ -47,7 +47,9 @@ We are going to decouple the deployment from the build, test, and release portio - The [Environment], [SnapshotEnvironmentBinding], and [GitOpsDeploymentManagedEnvironment] resources will be deprecated and eventually decomissioned. -- The [application-service] will stop generating GitOps repo content. +- The [application-service] will stop generating GitOps repo content and stop creating GitOps + repositories. +- We will stop deploying the [gitops-service] entirely and the RDS instance it uses. - HAC will stop rendering [Environments] and their status. - If a user wants to make use of deployment capabilities, we will promote the usage of [renovatebot] to propagate _released_ images to their self-managed gitops repo as pull requests. Dependabot is @@ -112,36 +114,38 @@ flowchart TD Outside of the AppStudio member cluster, the user is responsible for acquiring a gitops repo and deployment environments of their choice, manually laying out their application resources in the repo (assisted by tools like `kam`), specifying image references by tag to match the `:released` or -`:validated` tagging schem mentioned above, configuring Argo to deploy from their gitops repo, and -configuring [renovatebot] to propagate image updates by digest to their gitops repo. +`:validated` tagging schem mentioned above, configuring ArgoCD to deploy from their gitops repo, and +configuring [renovatebot] to propagate image updates by digest to their gitops repo. Really, ArgoCD +here is just an example and other gitops tools can be used. It can even update Helm repos with the +new images. Options for the user are not limited. **For manual creation of new environments** - the user manages this directly using a combination of their gitops repo and argo, outside of the AppStudio member cluster. **For automated testing in ephemeral environments** - the user specifies an -[IntegrationTestScenario] CR with a [DeploymentTargetClass] reference. After a build completes, but -before it executes tests, the integration-service creates a new [DeploymentTargetClaim] CR with -a [DTCLS] matching the one on the [IntegrationTestScenario]. This should cause the -[deployment-target-operator] to provision and bind a [DeploymentTarget] matching the -[DeploymentTargetClass]. [integration-service] then passes the kubeconfig and [Snapshot] to the -integration test to deploy the user's app and run tests. The integration-service should delete the -[DTC] once it isn’t needed anymore for the test. +[IntegrationTestScenario] CR with a [DeploymentTargetClaim] *spec* embedded. After a build +completes, but before it executes tests, the integration-service creates a new +[DeploymentTargetClaim] CR with a spec copied from the one on the [IntegrationTestScenario]. This +should cause the [deployment-target-operator] to provision and bind a [DeploymentTarget] matching +the [DeploymentTargetClass] referenced in the spec. [integration-service] then passes the kubeconfig +and [Snapshot] to the integration test to deploy the user's app and run tests. The +integration-service should delete the [DTC] once it isn’t needed anymore for the test. ```mermaid flowchart TD User --> |provides| IntegrationTestScenario - IntegrationTestScenario --> |references| DeploymentTargetClass + IntegrationTestScenario --> |embeds| spec[DeploymentTargetClaim spec] commit[fa:fa-code-commit Git Commit] --> |webhook| PipelinesAsCode PipelinesAsCode --> |creates| build[Build PipelineRun] build --> |triggers| integration-service integration-service --> |consults| IntegrationTestScenario + spec --> |is used to create| DeploymentTargetClaim integration-service --> |creates| DeploymentTargetClaim - DeploymentTargetClaim --> |references| DeploymentTargetClass DeploymentTargetClaim --> |is bound to| DeploymentTarget DeploymentTarget --> |is associated with| kubeconfig[kubeconfig Secret] kubeconfig --> |is provided to| test integration-service --> |creates| test[Test PipelineRun] - DeploymentTarget --> |represents| cluster + DeploymentTarget --> |represents| cluster[cluster, namespace, or other external resource] test --> |deploys user app to| cluster test --> |executes tests against| cluster ``` @@ -158,9 +162,11 @@ flowchart TD - As a team, we'll be in a position to try to achieve independence for the [DeploymentTarget] APIs, make it usable outside the context of AppStudio, and ideally make it attractive for collaborators. -## Phases of implementation +## Implementation -- Create the [deployment-target-operator], as step 0. +Some of these phases can be done at the same time. + +- Create the [deployment-target-operator]. - [integration-service]: use [DTCs] directly instead of [Environments]. - [release-service]: Drop the environment reference from the [ReleasePlanAdmission] spec, and related controller code for managing a [SnapshotEnvironmentBinding]. @@ -168,8 +174,10 @@ flowchart TD - [HAC]: Drop UI features showing the [Environments]: (commit view, Environments pane, etc.) - [integration-service]: stop creating a [SEB] for the lowest [Environments]. - [application-service]: stop generating the gitops repo content in response to [SEBs]. +- [application-service]: stop creating gitops repos. - Drop the [Environment], [SnapshotEnvironmentBinding], and [GitOpsDeploymentManagedEnvironment] APIs from the [application-api] repo. +- Stop deploying the [gitops-service] and decomission the RDS database. [renovatebot]: https://github.com/renovatebot/renovate [deployment-target-operator]: # From 39601e0769e5f6e26873f019b1652feca7d52db7 Mon Sep 17 00:00:00 2001 From: Ralph Bean Date: Tue, 5 Dec 2023 16:34:22 -0500 Subject: [PATCH 11/15] Style, formatting, broken link --- ADR/0032-decoupling-deployment.md | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/ADR/0032-decoupling-deployment.md b/ADR/0032-decoupling-deployment.md index 6b678ba8..dbb75f0d 100644 --- a/ADR/0032-decoupling-deployment.md +++ b/ADR/0032-decoupling-deployment.md @@ -7,12 +7,14 @@ Date: 2023-11-17 Draft Relates to: -* [ADR 14. Let Pipelines Proceed](0014-let-pipelines-proceed.html) + +- [ADR 14. Let Pipelines Proceed](0014-let-pipelines-proceed.html) Supercedes: -* [ADR 08. Environment Provisioning](0008-environment-provisioning.html) -* [ADR 16. Integration Service Promotion Logic](0016-integration-service-promotion-logic.html) -* [ADR 28. Handling SnapshotEnvironmentBinding Errors](0028-handling-snapshotenvironmentbinding-errors.html) + +- [ADR 08. Environment Provisioning](0008-environment-provisioning.html) +- [ADR 16. Integration Service Promotion Logic](0016-integration-service-promotion-logic.html) +- [ADR 28. Handling SnapshotEnvironmentBinding Errors](0028-handling-snapshotenvironmentbinding-errors.html) ## Authors @@ -187,6 +189,8 @@ Some of these phases can be done at the same time. [application-service]: ../architecture/application-service.md [integration-service]: ../architecture/integration-service.md [release-service]: ../architecture/release-service.md +[Application]: ../ref/application-environment-api.md#application +[Applications]: ../ref/application-environment-api.md#application [Component]: ../ref/application-environment-api.md#component [Components]: ../ref/application-environment-api.md#component [Environment]: ../ref/application-environment-api.md#environment From 9acabdcc0e632c13c2b8772d9ac8e75597e2b725 Mon Sep 17 00:00:00 2001 From: Ralph Bean Date: Mon, 8 Jan 2024 11:52:10 -0500 Subject: [PATCH 12/15] Update Decoupling Deployments in light of dynamic resource allocation APIs --- ADR/0032-decoupling-deployment.md | 86 ++++++++++++++++++------------- 1 file changed, 49 insertions(+), 37 deletions(-) diff --git a/ADR/0032-decoupling-deployment.md b/ADR/0032-decoupling-deployment.md index dbb75f0d..c2d52956 100644 --- a/ADR/0032-decoupling-deployment.md +++ b/ADR/0032-decoupling-deployment.md @@ -59,18 +59,23 @@ We are going to decouple the deployment from the build, test, and release portio **Test and promotion**: -- We will retain the [DeploymentTargetClaim], [DeploymentTarget], and [DeploymentTargetClass] APIs. - Collectively, call these the "DTC" APIs. These should have no dependence on other AppStudio APIs. - Only [integration-service] should depend on them. The controllers that support the DTC API should - be organized into their own project: "the [deployment-target-operator]", or something like that. -- [integration-service] should be modified to create and destroy [DeploymentTargetClaims] directly - instead of [Environment] resources. Users will be expected to provide integration test pipelines - that accept a kubeconfig and snapshot as they do now, but those pipelines should now take initial - steps to *deploy the instance of their application to be tested* to the deployment target provided - by [integration-service] using the provided kubeconfig. -- We should promote [release-service] as the primary means to advertise to [renovatebot] that one or - more images have passed testing and are ready to be promoted to a particular environment (with - a lowercase "e") by way of image tags in a registry. +- We will decomission the [DeploymentTargetClaim], [DeploymentTarget], and [DeploymentTargetClass] + APIs in favor of the new [Dynamic Resource Allocation APIs] that are an alpha feature of Kubernetes + v1.27 and OpenShift 4.14. +- [integration-service] should no longer create and and manage [Environments] and the related + [DeploymentTargetClaims]. Users will be expected to provide integration test pipelines that (somehow) + specify `resourceClaims`, which will cause a provisioner to provision the compute and inject a + kubeconfig for the target compute into the taskrun pod. The user's test pipeline should then take + steps to *deploy an instance of their application to be tested* to the compute provided by dynamic + resource allocation provisioner, using using the provided kubeconfig. +- In the intervening time between now and when the Dynamic Resource Allocation APIs are available + (OpenShift 4.14 plus the time we need to implement a sandbox SpaceRequest *resource driver*), users + that need an ephemeral namespace for testing will need to employ a Task as the first step in their + pipeline that creates a SpaceRequest. They will need to use a finally task to clean up the SpaceRequest + after testing completes. +- We should promote [release-service] as the primary means to advertise to [renovatebot] that one or more + images have passed testing and are ready to be promoted to a particular environment (with a lowercase + "e") by way of image tags in a registry. ### Out of scope @@ -118,38 +123,39 @@ deployment environments of their choice, manually laying out their application r (assisted by tools like `kam`), specifying image references by tag to match the `:released` or `:validated` tagging schem mentioned above, configuring ArgoCD to deploy from their gitops repo, and configuring [renovatebot] to propagate image updates by digest to their gitops repo. Really, ArgoCD -here is just an example and other gitops tools can be used. It can even update Helm repos with the -new images. Options for the user are not limited. +here is just an example and other gitops tools could be used; renovate could even update Helm repos +with the new images. Options for the user are not limited. **For manual creation of new environments** - the user manages this directly using a combination of their gitops repo and argo, outside of the AppStudio member cluster. **For automated testing in ephemeral environments** - the user specifies an -[IntegrationTestScenario] CR with a [DeploymentTargetClaim] *spec* embedded. After a build -completes, but before it executes tests, the integration-service creates a new -[DeploymentTargetClaim] CR with a spec copied from the one on the [IntegrationTestScenario]. This -should cause the [deployment-target-operator] to provision and bind a [DeploymentTarget] matching -the [DeploymentTargetClass] referenced in the spec. [integration-service] then passes the kubeconfig -and [Snapshot] to the integration test to deploy the user's app and run tests. The -integration-service should delete the [DTC] once it isn’t needed anymore for the test. +[IntegrationTestScenario] CR, which references a pipeline which (somehow) creates a `resourceClaim`. +After a build completes, the [integration-service] creates the PipelineRun which causes the **resource +driver** associated with the `resourceClaim` to provision the requested compute. The resource driver +injects the kubeconfig for the ephemeral compute into the pod, to be used by the test TaskRun. The +user's test TaskRun is responsible for deploying the user's app based on the [Snapshot] provided by +[integration-service] as a parameter and the kubeconfig injected into the TaskRun pod by the resource +driver before running tests. The resource driver should cleanup after itself after the test TaskRun +and its corresponding pod complete. ```mermaid flowchart TD User --> |provides| IntegrationTestScenario - IntegrationTestScenario --> |embeds| spec[DeploymentTargetClaim spec] + User --> |provides| testpipeline commit[fa:fa-code-commit Git Commit] --> |webhook| PipelinesAsCode PipelinesAsCode --> |creates| build[Build PipelineRun] build --> |triggers| integration-service integration-service --> |consults| IntegrationTestScenario - spec --> |is used to create| DeploymentTargetClaim - integration-service --> |creates| DeploymentTargetClaim - DeploymentTargetClaim --> |is bound to| DeploymentTarget - DeploymentTarget --> |is associated with| kubeconfig[kubeconfig Secret] - kubeconfig --> |is provided to| test - integration-service --> |creates| test[Test PipelineRun] - DeploymentTarget --> |represents| cluster[cluster, namespace, or other external resource] - test --> |deploys user app to| cluster - test --> |executes tests against| cluster + IntegrationTestScenario --> |references| testpipeline + testpipeline --> |is used to create| testpipelinerun + testpipelinerun --> |prompts| driver[Resource Driver] + driver --> |creates| compute[Compute - cluster, namespace, or other external resource] + driver --> |creates| kubeconfig + kubeconfig --> |is injected into pod of| testpipelinerun[Test PipelineRun] + integration-service --> |creates| testpipelinerun[Test PipelineRun] + testpipelinerun --> |deploys user app to| compute + testpipelinerun --> |executes tests against| compute ``` ## Consequences @@ -161,26 +167,32 @@ flowchart TD - Users who expect to provide and manage their own resources to control their app will be delighted. They now no longer have to interact with an intermediary API to try to express details about their deployment(s). -- As a team, we'll be in a position to try to achieve independence for the [DeploymentTarget] APIs, +- As a team, we'll be in a better position to try to achieve independence for [integration-service], make it usable outside the context of AppStudio, and ideally make it attractive for collaborators. ## Implementation Some of these phases can be done at the same time. -- Create the [deployment-target-operator]. -- [integration-service]: use [DTCs] directly instead of [Environments]. +- Work with the only known users of ephemeral environments right now (Exhort team) to create the + intermediary solution: a pair of tekton tasks that create and destroy SpaceRequests. Use this + in their pipelines to drop usage of the existing Environment-cloning feature set. +- Create a Dynamic Resource Allocation resource driver that supports SpaceBindings +- [integration-service]: Drop the environment reference from the [IntegrationTestScenario] spec, + and related controller code for managing ephemeral [Environments] for tests. - [release-service]: Drop the environment reference from the [ReleasePlanAdmission] spec, and related controller code for managing a [SnapshotEnvironmentBinding]. -- [HAC]: update [IntegrationTestScenario] CRUD to use [DTCs] instead of [Environments]. +- [HAC]: update [IntegrationTestScenario] no longer use [Environments]. - [HAC]: Drop UI features showing the [Environments]: (commit view, Environments pane, etc.) - [integration-service]: stop creating a [SEB] for the lowest [Environments]. - [application-service]: stop generating the gitops repo content in response to [SEBs]. - [application-service]: stop creating gitops repos. -- Drop the [Environment], [SnapshotEnvironmentBinding], and [GitOpsDeploymentManagedEnvironment] - APIs from the [application-api] repo. +- Drop the [Environment], [SnapshotEnvironmentBinding], [GitOpsDeploymentManagedEnvironment], + [DeploymentTarget], [DeploymentTargetClaim], and [DeploymentTargetClass] APIs from the + [application-api] repo. - Stop deploying the [gitops-service] and decomission the RDS database. +[Dynamic Resource Allocation APIs]: https://kubernetes.io/docs/concepts/scheduling-eviction/dynamic-resource-allocation/ [renovatebot]: https://github.com/renovatebot/renovate [deployment-target-operator]: # [gitops-service]: ../ref/gitops-service.md From fe7b8553c7d89fcb69b3700954172be0c3c76ec6 Mon Sep 17 00:00:00 2001 From: Ralph Bean Date: Mon, 8 Jan 2024 12:11:33 -0500 Subject: [PATCH 13/15] Reference ADR 22 from ADR 32 --- ADR/0022-secret-mgmt-for-user-workloads.md | 4 ++++ ADR/0032-decoupling-deployment.md | 3 +++ 2 files changed, 7 insertions(+) diff --git a/ADR/0022-secret-mgmt-for-user-workloads.md b/ADR/0022-secret-mgmt-for-user-workloads.md index 7dbaa322..5e9cd8c8 100644 --- a/ADR/0022-secret-mgmt-for-user-workloads.md +++ b/ADR/0022-secret-mgmt-for-user-workloads.md @@ -7,6 +7,10 @@ Date revised: 2023-08-29 Accepted +Relates to: + +- [ADR 32. Decoupling Deployment](0032-decoupling-deployment.html) + ## Context * When user workloads are deployed to environments, the system should be able to provide a way to inject values that are specific to the environment. Currently, this is done through environment variables that are managed as overlays on the GitOps repository for the application. However, this method does not provide a good way to manage `Secret`. This ADR addresses the secret management of user workloads for different environments. diff --git a/ADR/0032-decoupling-deployment.md b/ADR/0032-decoupling-deployment.md index c2d52956..69a8e5fe 100644 --- a/ADR/0032-decoupling-deployment.md +++ b/ADR/0032-decoupling-deployment.md @@ -9,6 +9,7 @@ Draft Relates to: - [ADR 14. Let Pipelines Proceed](0014-let-pipelines-proceed.html) +- [ADR 22. Secret Management for User Workloads](0022-secret-mgmt-for-user-workloads.html) Supercedes: @@ -184,6 +185,8 @@ Some of these phases can be done at the same time. related controller code for managing a [SnapshotEnvironmentBinding]. - [HAC]: update [IntegrationTestScenario] no longer use [Environments]. - [HAC]: Drop UI features showing the [Environments]: (commit view, Environments pane, etc.) +- [HAC]: Drop UI features differentiating "build" and "deploy" secrets. With this change, "deploy" + secrets are no longer relevant. - [integration-service]: stop creating a [SEB] for the lowest [Environments]. - [application-service]: stop generating the gitops repo content in response to [SEBs]. - [application-service]: stop creating gitops repos. From 045b0bb84fdd0c93f095d07cff4a81e22f4fb16b Mon Sep 17 00:00:00 2001 From: Martin Date: Fri, 12 Jan 2024 18:57:31 +0100 Subject: [PATCH 14/15] fix(STONEINTG-598): Clarify required integration test scenarios (#161) Clarify that only required test scenarios are blocking for processing of snapshot. If scenario is marked as optional, any results won't block further processing of snapshot. Signed-off-by: Martin Basti --- architecture/integration-service.md | 25 +++++++++++++------------ 1 file changed, 13 insertions(+), 12 deletions(-) diff --git a/architecture/integration-service.md b/architecture/integration-service.md index 17662748..dea8230c 100644 --- a/architecture/integration-service.md +++ b/architecture/integration-service.md @@ -20,7 +20,7 @@ The Integration service uses the pipeline, snapshot, and environment controllers - When a build pipeline completes, Integration service creates a Snapshot CR representing a new collection of components that should be tested together. - When Integration Service sees a new Snapshot CR (created either by itself or by a user), it coordinates deployment of the application for testing. It does this by creating new “ephemeral” AppStudio Environment CRs which trigger the GitOps Service to provision the ephemeral test environment. - After the environment is ready and the application snapshot has been deployed to it, Integration Service tests and validates the application according to user-provided configuration. It does this by executing Tekton PipelineRuns against the ephemeral test Environment. -- When all of the test Tekton PipelineRuns have passed, Integration service triggers a deployment of the application to all Environments which are not labeled as "ephemeral" and which do not have a `parentEnvironment` set. For most users, this will result in a deployment to their "development" environment (or to their "staging" environment, if they do not have a dev environment). +- When all of the required test Tekton PipelineRuns have passed, Integration service triggers a deployment of the application to all Environments which are not labeled as "ephemeral" and which do not have a `parentEnvironment` set. For most users, this will result in a deployment to their "development" environment (or to their "staging" environment, if they do not have a dev environment). - Finally, if any automatic ReleasePlans have been created by the user in the workspace, it will create a Release CR signalling intent to release the tested content, to be carried out by the [release-service](./release-service.md). The diagram below shows the interaction of the integration service and other services. @@ -51,7 +51,7 @@ The [Integration Service](./integration-service.md) is dependent on the followin **Composite Pipeline** - This is the pipeline run that runs if two or more Components have completed and passed their Component pipeline concurrently so that they should be tested together. -**Global Candidate List** - The list of all Component digest that have passed individual component testing. This can be retrieved from the Application to see what Components it is made of and then querying each of the Components `spec.containerImage`. +**Global Candidate List** - The list of all Component digest that have passed individual component testing. This can be retrieved from the Application to see what Components it is made of and then querying each of the Components `spec.containerImage`. **Snapshot** - The custom resource that contains the list of all Components of an Application with their Component Image digests. Once created, the list of Components with their images is immutable. The Integration service updates the status of the resource to reflect the testing outcome. @@ -67,7 +67,7 @@ The [Integration Service](./integration-service.md) is dependent on the followin **Final Pipeline** - This is the same as the Composite Pipeline. Going forward the Final Pipeline will be referred as Composite Pipeline. -## Resources +## Resources Below are the list of CRs that the integration service is responsible for interacting and performing operations: ### CREATE @@ -113,7 +113,7 @@ The test pipeline will consist of a single definition that could be executed as - Component pipeline run - Composite pipeline run -The Component pipeline run is always triggered for each Component of an Application and is triggered by a completed build of a component. +The Component pipeline run is always triggered for each Component of an Application and is triggered by a completed build of a component. The Composite pipeline run is only triggered when it has been determined by the Integration Service that two or more Components of an Application have been successfully built concurrently by their respective Component pipeline and need to be tested together. @@ -140,7 +140,7 @@ The Integration service will copy the annotations and labels from the Build Pipe The "test.appstudio.openshift.io/optional" Label provides users an option whether the result of a pipelineRun created according to the IntegrationTestScenario will be taken into account when determining if the Snapshot has passed all required testing. In another word, the label is used to specify if an IntegrationTestScenario is allowed to fail. If the label is not defined in an IntegrationTestScenario, integration service will consider it as "false". ``` -"test.appstudio.openshift.io/optional": "false"|"true" +"test.appstudio.openshift.io/optional": "false"|"true" ``` The label will be copied to the subsequent Test PipelineRuns. @@ -161,7 +161,7 @@ The Integration service needs secrets mounted so that the `Environment Provision ## Detailed Workflow 1. Watch for Build PipelineRuns of `type: build` - Extract Component Name, Application Name, and Image from pipeline annotations -2. Query the Application +2. Query the Application - for each Component extract the `spec.containerImage` 3. Create a Snapshot - Populate the `spec.components` list with the component name and the `spec.containerImage` with information from Step 1 and 2, replacing the container image for the built component with the one from the build PipelineRun @@ -178,11 +178,12 @@ The Integration service needs secrets mounted so that the `Environment Provision - Pass in the Snapshot json representation as a parameter - Optional: Create the ephemeral Environment if the IntegrationTestScenario specifies one. After the Environment is ready, link it to the pipelineRun and start it 5. Watch the PipelineRun of `test: component` and `component: ` - - When all PipelineRuns complete - - Check if all the PipelineRuns associated with the snapshot have passed successfully - - If all PipelineRuns passed, mark the Snapshot as validated by setting its status condition `HACBSTestsSucceeded` as true - - If not all PipelineRuns passed, mark the Snapshot as not validated by setting its status condition `HACBSTestsSucceeded` as false, end the Integration testing process -6. Update the Component `spec.containerImage` + - When all required PipelineRuns complete + - Check if all the required PipelineRuns associated with the snapshot have passed successfully + - If all required PipelineRuns passed, mark the Snapshot as validated by setting its status condition `HACBSTestsSucceeded` as true + - If not all required PipelineRuns passed, mark the Snapshot as not validated by setting its status condition `HACBSTestsSucceeded` as false, end the Integration testing process + - Note: Users are allowed to mark an Integration Test Scenario as optional. In this case results of testing are ignored for the optional scenario and don't block further processing of the Snapshot. +6. Update the Component `spec.containerImage` 7. Query the Application and find all of its components - For each Component extract the `spec.containerImage` 8. Prepare a new Snapshot @@ -198,7 +199,7 @@ The Integration service needs secrets mounted so that the `Environment Provision 12. Create a Release with the `spec.ReleasPlan` and `spec.Snapshot` 13. Done - Repeat from Step 1 again 14. If not the same, repeat step 4 - - Assign the same annotations except + - Assign the same annotations except Test: composite Snapshot: name from step 8 - Pass in the Snapshot name as a parameter From a28a539b06a3eea0227e4a8687d9b82231e854c2 Mon Sep 17 00:00:00 2001 From: Ralph Bean Date: Thu, 1 Feb 2024 10:25:33 -0500 Subject: [PATCH 15/15] Move ADR 32 to accepted --- ADR/0032-decoupling-deployment.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/ADR/0032-decoupling-deployment.md b/ADR/0032-decoupling-deployment.md index 69a8e5fe..18d2eda8 100644 --- a/ADR/0032-decoupling-deployment.md +++ b/ADR/0032-decoupling-deployment.md @@ -1,10 +1,11 @@ # 32. Decoupling Deployment -Date: 2023-11-17 +Date started: 2023-11-17 +Date accepted: 2023-02-01 ## Status -Draft +Accepted Relates to: