Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DEV-123: Update Release Engineering docs to include snippet on consolidating workflows #708

Open
wants to merge 4 commits into
base: master
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
85 changes: 84 additions & 1 deletion docs/layers/software-delivery/software-delivery.mdx
Original file line number Diff line number Diff line change
@@ -1,6 +1,5 @@
---
title: Software Delivery
sidebar_class_name: hidden
---
import Intro from '@site/src/components/Intro';
import Steps from '@site/src/components/Steps';
Expand Down Expand Up @@ -58,3 +57,87 @@ import ReactPlayer from 'react-player';

Once you're done deploying your apps, it's time to start monitoring everything. We'll show you how to do that next.

<hr></hr>
<h2>Our Examples</h2>

### Reusable Workflows

We've consolidated all the workflows into the example applications,
including the GitHub reusable workflows.
We've done this to make it easier for Developers to understand how the example leverages all the workflows.
In practice, we recommend moving the reusable workflows into a centralized repository,
where they can be shared by other application repositories.

For example,
we would recommend moving all the `ecspresso-*` and all `workflow-*` workflow files to a centralized repository
(e.g. a repository named `github-action-workflows`, alternatively the `infrastructure` repository directly).
The best solution will depend on your GitHub Organization structure and team size.
Pick what works for you and your team.

When your workflows are consolidated, you will need only 3 inside an application repository:

1. `feature-branch.yaml`
2. `main-branch.yaml`
3. `release.yaml`
4. (optional) `hotfix-branch.yaml`
5. (optional) `hotfix-enabled.yaml`
6. (optional) `hotfix-release.yaml`

The remaining workflows are the reusable/shared implementation. This approach makes it easier to define a standardized CI/CD interface for all of your services.

```console
.github
├── configs/
│ ├── draft-release.yml
│ └── environment.yaml
└── workflows/
├── ecspresso-feature-branch.yml
├── ecspresso-hotfix-branch.yml
├── ecspresso-hotfix-mixin.yml
├── ecspresso-hotfix-release.yml
├── ecspresso-main-branch.yml
├── ecspresso-release.yml
├── feature-branch.yml
├── main-branch.yaml
├── release.yaml
├── workflow-cd-ecspresso.yml
├── workflow-cd-preview-ecspresso.yml
├── workflow-ci-dockerized-app-build.yml
├── workflow-ci-dockerized-app-promote.yml
├── workflow-controller-draft-release.yml
├── workflow-controller-hotfix-reintegrate.yml
├── workflow-controller-hotfix-release-branch.yml
└── workflow-controller-hotfix-release.yml
```

After moving to a centralized workflow repository, you should have a setup like the following:

```console
Application Repository
├── .github
│ ├── configs/
│ │ └── draft-release.yml
│ └── workflows/
│ ├── feature-branch.yml
│ ├── main-branch.yaml
│ └── release.yaml
└── ...
github-action-workflows
├── .github/
│ └── workflows
│ ├── ecspresso-feature-branch.yml
│ ├── ecspresso-hotfix-branch.yml
│ ├── ecspresso-hotfix-mixin.yml
│ ├── ecspresso-hotfix-release.yml
│ ├── ecspresso-main-branch.yml
│ ├── ecspresso-release.yml
│ ├── workflow-cd-ecspresso.yml
│ ├── workflow-cd-preview-ecspresso.yml
│ ├── workflow-ci-dockerized-app-build.yml
│ ├── workflow-ci-dockerized-app-promote.yml
│ ├── workflow-controller-draft-release.yml
│ ├── workflow-controller-hotfix-reintegrate.yml
│ ├── workflow-controller-hotfix-release-branch.yml
│ └── workflow-controller-hotfix-release.yml
└── ...
```