@@ -8,20 +8,21 @@ like "prerelease" (GitHub), distribution tags (npm), suffix "-SNAPSHOT" (maven),
88Idea: 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
1313The 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
2728Dev 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 .
5572So we do not need dev-release, right?_
5673
5774Build-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!
5976Imagine 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`.
6077And only C has a "Deploy" button!
6178Now, 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