Skip to content

Commit

Permalink
feat(STONEINTG-698): remove ephemeral environment references
Browse files Browse the repository at this point in the history
* Remove all references to ephemeral environments from
  the integration service architecture document

Signed-off-by: dirgim <kpavic@redhat.com>
  • Loading branch information
dirgim committed Apr 25, 2024
1 parent 2412d59 commit 94a2a11
Showing 1 changed file with 6 additions and 28 deletions.
34 changes: 6 additions & 28 deletions architecture/integration-service.md
Original file line number Diff line number Diff line change
Expand Up @@ -5,11 +5,11 @@

The Integration Service is composed of controllers that facilitate automated testing of content produced by the build pipelines. It is mainly responsible for integration testing capabilities.

The Integration service uses the pipeline, snapshot, and environment controllers to watch for Component builds, trigger and manage testing Tekton Pipelines, and create releases based on the testing outcome(s).
The Integration service uses a number of pipeline, snapshot, scenario and component controllers to watch for Component builds, trigger and manage testing Tekton Pipelines, and create releases based on the testing outcome(s).

### Goals

- The Integration service need to be able to deploy a specific set of images to an environment and record the results of integration testing.
- The Integration service need to be able to test a specific set of images and record the results of integration testing.
- Given a specific set of images, Integration service should be able to tell if they passed application validation tests.
- The Integration service should be able to update one component image at a time in order to test and deploy individual component builds.
- The Integration service should have a capability to automatically promote sets of passed images.
Expand All @@ -18,10 +18,9 @@ The Integration service uses the pipeline, snapshot, and environment controllers
### High Level Workflow

- 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 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).
- When Integration Service sees a new Snapshot CR (created either by itself or by a user), it coordinates testing of that Snapshot.
- Integration Service tests and validates the application according to user-provided configuration. It does this by executing Tekton PipelineRuns based on user-defined Integration Test Scenarios.
- When all the required test Tekton PipelineRuns have passed and 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.

Expand All @@ -32,11 +31,6 @@ The diagram below shows the interaction of the integration service and other ser
The [Integration Service](./integration-service.md) is dependent on the following services:
- [Pipeline Service](./pipeline-service.md)
- Pipeline execution, Pipeline logging
- [GitOps Service](./gitops-service.md)
- Provides the facility to create
- Snapshots defining sets of Builds to test
- Environment to test the Application on
- SnapshotEnvironmentBindings to have the Snapshot of the Application deployed to a specific Environment
- [Hybrid Application Service](./hybrid-application-service.md)
- Provides the Application and Component model. Integration Service updates the pullspec reference on the Component CR when a component passes its required testing.
- [Release Service](./release-service.md)
Expand All @@ -57,8 +51,6 @@ The [Integration Service](./integration-service.md) is dependent on the followin

**IntegrationTestScenario** - The custom resource that describes separate PipelineRuns that are supposed to be run by the snapshot controller. The IntegrationTestScenarios can be marked as optional, in which case they will not be taken into account when determining if the Snapshot has passed testing. Any number of IntegrationTestScenarios can be set by the user and also the user can specify the contexts where they will be applied (Component or Composite stage - or both).

**Ephemeral Environment** - The ephemeral copy of an existing environment that is created by the Integration service for use during a specific Integration pipeline run.

**SLSA** - [SLSA](http://slsa.dev/) is a new PSSC initiative. Current goal is to reach [SLSA](http://slsa.dev/) level 4 or above for all services.

## Outdated Terminology
Expand Down Expand Up @@ -146,18 +138,6 @@ The label will be copied to the subsequent Test PipelineRuns.

The `test.appstudio.openshift.io/kind` annotation is an optional annotation that can be used to filter on the kinds of `IntegrationTestScenario`s. The first recognized kind is the `enterprise-contract`. It will be copied to the `PipelineRun`s resulting from the `IntegrationTestScenario`.

#### Workspace

The Integration service will provide Tekton workspaces to the individual PipelineRuns to supply additional resources required for testing, such as secure credentials for accessing test Environments.

#### Persistent Volume

A persistent volume that the pipeline can store test artifacts generated from the test execution.

#### Secrets

The Integration service needs secrets mounted so that the `Environment Provisioner` Task running in the workspace has the correct permissions to create AppStudio Application Environments resources within the Applications/Component’s namespace.

## Detailed Workflow
1. Watch for Build PipelineRuns of `type: build`
- Extract Component Name, Application Name, and Image from pipeline annotations
Expand All @@ -167,7 +147,7 @@ The Integration service needs secrets mounted so that the `Environment Provision
- 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
- If a component does not have a container image associated with it then the component will not be added to the snapshot
4. Create PipelineRuns for each IntegrationTestScenario
- Fetch the IntegrationTestScenario for the application/component to get the Tekton Bundle and Environment information
- Fetch the IntegrationTestScenario for the application/component to get the Tekton reference information.
- Assign annotations of
```
"test.appstudio.openshift.io/test": component
Expand All @@ -176,7 +156,6 @@ The Integration service needs secrets mounted so that the `Environment Provision
“test.appstudio.openshift.io/application": “<Application name>”
```
- 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: <component name>`
- When all required PipelineRuns complete
- Check if all the required PipelineRuns associated with the snapshot have passed successfully
Expand Down Expand Up @@ -229,7 +208,6 @@ Integration service is getting specific information about the image that's being
## Appendix
- [AppStudio Promotion & Environment API](https://docs.google.com/document/d/14LaXAmQEW73kIr3a6TvPswT-zSdBsuaaxLF77HJ3gX4/edit#)
- [v3 - Environment API draft: Component-scoped with native Snapshots](https://docs.google.com/document/d/1-_rWLgALd5pdSlqNNcQ5FSrD00fZb0l_exU-_FiL68o/edit#heading=h.vf66svd4o6xr)
- [AppStudio builds and tests PRs](https://docs.google.com/document/d/113XTplEWRM63aIzk7WwgLruUBu2O7xVy-Zd_U6yjYr0/edit#)
- [Labels and Annotations for AppStudio pipelines](https://docs.google.com/document/d/1fJq4LDakLfcAPvOOoxxZNWJ_cuQ1ew9jfBjWa-fEGLE/edit#)
- [Implementation design and rules for pipeline customization](https://docs.google.com/document/d/1PXkpFHKrnq1Sg1giTgeXdYzNVf7CTRgwowykr7YPM2I/edit#)
Expand Down

0 comments on commit 94a2a11

Please sign in to comment.