Skip to content

Commit 32f2f50

Browse files
committed
docs: review with AI-6 [skip ci]
1 parent cad4f67 commit 32f2f50

File tree

2 files changed

+43
-26
lines changed

2 files changed

+43
-26
lines changed

docs/artifact-types/index.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -5,5 +5,5 @@
55
- [Publish in AWS ECR](./aws-ecr.md)
66
- [Publish in AWS CodeArtifact Maven repository](./aws-codeartifact-maven.md)
77
- Non-AWS
8-
- [Publish in npmjs repo](./npmjs.md)
8+
- [Publish in npmjs](./npmjs.md)
99
- [No artifacts, just git tags](./git.md)

docs/features/dev-release.md

Lines changed: 42 additions & 25 deletions
Original file line numberDiff line numberDiff line change
@@ -8,20 +8,21 @@ like "prerelease" (GitHub), distribution tags (npm), suffix "-SNAPSHOT" (maven),
88
Idea: release a version widely available for testing and with potential to become the next major release
99

1010
**dev-release** is a way to overcome the inability to spin up the entire env locally.
11-
It allows you to temporarily release a version (= branch name), so that now you can deploy it in sandbox or dev environment for testing or POC
11+
It allows you to temporarily release a version (= branch name), so that you can deploy it in sandbox or dev environment for testing or POC
1212

1313
The table below shows a comparison of different release types:
1414

15-
| Name | normal release and maintenance release | prerelease | dev-release |
16-
|-----------------------------|----------------------------------------|---------------------------------------|-----------------------|
17-
| intention | use in production | beta testing | dev testing |
18-
| best use for | software packages and deployable apps | software packages and deployable apps | deployable apps |
19-
| adoption | widely | widely | popular in enterprise |
20-
| version generation | "semantic commits" or "version-bump" | "semantic commits" or "version bump" | version = branch name |
21-
| auto deletion | ❌️ | ❌️ ||
22-
| number of developers | many | many | typically one |
23-
| release notes and changelog ||| ❌️ |
24-
| floating tags | major, minor, latest | alpha/beta/rc | ❌️ |
15+
| Name | normal release and maintenance release | prerelease | dev-release |
16+
|-----------------------------|-----------------------------------------------|-----------------------------------------------|--------------------------|
17+
| intention | use in production | beta testing | dev testing |
18+
| best use for | software packages and deployable apps | software packages and deployable apps | deployable apps |
19+
| adoption | widely | widely | popular in enterprise |
20+
| version generation | "semantic commits" or "version-bump" | "semantic commits" or "version bump" | version = branch name |
21+
| auto deletion | ❌️ | ❌️ ||
22+
| number of developers | many | many | typically one |
23+
| release notes and changelog ||| ❌️ |
24+
| floating tags | major, minor, latest | alpha / beta / rc | ❌️ |
25+
| trigger | push in protected branch (including PR merge) | push in protected branch (including PR merge) | Manual workflow dispatch |
2526

2627

2728
Dev release allows publishing artifacts temporarily for testing purposes:
@@ -32,30 +33,46 @@ you push your changes to the feature branch, the branch name becomes this dev-re
3233
- `/` gets replaced with `-`, so branch `feature/login` gives version `feature-login`
3334
- parameter `dev-branch-prefix` (default value is `feature/`) enforces branch naming for dev releases.
3435
This is needed for security and automatic resource disposal. Set to an empty string to disable such enforcement (not recommended)
35-
- for each [artifact type](./../artifact-types/index.md), dev-release might have different semantics, see `dev-release` section for each artifact type
36+
- for each [artifact type](./../artifact-types/index.md), dev-release might have different semantics,
37+
see "dev-release" section for each artifact type
38+
39+
dev-release workflow blueprint:
3640

37-
Example of 'dev-release' usage with AWS S3:
3841
```yaml
39-
steps:
40-
- name: Release
41-
uses: agilecustoms/release@v1
42-
with:
43-
aws-account: ${{ vars.AWS_ACCOUNT_DIST }}
44-
aws-region: us-east-1
45-
aws-role: 'ci/publisher-dev' # see "Security" section below
46-
aws-s3-bucket: 'mycompany-dist'
47-
dev-release: true
48-
dev-release-prefix: 'feature/' # default
42+
name: Dev Release
43+
44+
on:
45+
workflow_dispatch:
46+
47+
jobs:
48+
# ...
49+
Release:
50+
# ...
51+
steps:
52+
# ...
53+
- name: Release
54+
uses: agilecustoms/release@v1
55+
with:
56+
aws-account: ${{ vars.AWS_ACCOUNT_DIST }}
57+
aws-region: us-east-1
58+
aws-role: 'ci/publisher-dev' # see "Security" section below
59+
aws-s3-bucket: 'mycompany-dist'
60+
dev-release: true
61+
dev-release-prefix: 'feature/' # default
4962
```
5063
64+
Complete examples:
65+
- [AWS S3](../examples/env-api/.github/workflows/release-dev.yml), see [details](../artifact-types/aws-s3.md#dev-release)
66+
- [AWS ECR](../examples/env-cleanup/.github/workflows/release-dev.yml), see [details](../artifact-types/aws-ecr.md#dev-release)
67+
5168
## Motivation
5269
5370
_How did we live without a dev-release before?
54-
We do use microservices in our team, and we just have a CI/CD pipeline that can build a feature branch and deploy it to a dev server.
71+
We do use microservices in our team, and we just have a CI/CD pipeline that can build a feature branch and deploy it to a dev environment.
5572
So we do not need dev-release, right?_
5673
5774
Build-and-deploy is kind of a "shortcut" and it may work in simple scenarios.
58-
The reality is that a system is a _combination_ of multiple services, and true deployment takes a combination of services!
75+
The reality is that a system consists of multiple services, and true deployment takes a combination of services!
5976
Imagine a system that consists of two services A and B, and there is a repo C storing the current combination: `A@v1.0`, `B@v1.1`.
6077
And only C has a "Deploy" button!
6178
Now, you want to make a change in service A and test it, but since the only way to deploy a system is to deploy both services together,

0 commit comments

Comments
 (0)