Once a code change is validated the updated version can be packaged as a deployable artefact. Depending on your application this might be a Docker image, a compiled binary, an rpm or jar file, or simply a bundled and minified source file. This package must then be published to a location from which it can be deployed to relevant environments.
Use semantic version git tags on your repository to label and trigger alpha, beta and production builds. Our SemVer conventions are a subset of the SemVer v2.0.0 spec. A semantic version consists of:
majoris the major version number (integer). A major change for inner source projects is not necessarily a breaking change but rather one that is significant or complex enough to always require cross-team consensus and review.
minoris the minor version number (integer). A minor change for inner source projects is one that simple or routine enough that is can be released by the local in-team maintainer without cross-team consensus.
patchis the patch version number (integer). A patch change is a hotfix usually executed under incident conditions.
teamis the team code (string). This can be omitted when there is only a single owning team.
phaseis the release phase (
betaor not present for production).
integrationis an integer that indicates pre-release progression e.g. cumulative number of features, commits or similar.
buildis an integer that indicates build number (omitted if un-used).
By convention the version number is prefixed by a
v. For example:
v2.8.1 is the production
2.8 build after 1 hotfix.
v1.3.0-lds.beta.3 is a beta build for the intended
v1.3.0 release. It has been created by the
lds team, and has had several bugfixes applied which can be inferred from the
.3 integration number suffix.
v3.0.0-alpha.1 is an alpha build for the intended major
v3.0.0 release. It has no team element since all tags are created by a single team in this repository. The
.1 integration number suffix suggests this is an early build without many features yet.
git flutter CLI tool has various helper features to help you apply these tags easily and consistently to your repository.
GitHub provide in-built ‘release’ functionality where you can create a ‘release’ to package software, along with release notes and links to binary files, for other people to use. Using this feature is recommended.
COMING SOON: Some examples how teams create GitHub releases from git tags. This is not Flutter specific so you can use Google to find quality information in the meantime.
A common choice is to publish release artefacts from a repository into AWS for use within that ecosystem. For example, you might choose to publish a Docker image into the AWS container registry for use in AWS deployments:
COMING SOON: Case studies of Flutter teams using this flow.
GitHub Packages is a software package hosting service that allows you to host your software packages privately or publicly and use packages as dependencies in your projects. This is especially useful to publish library packages for re-use across other projects.
COMING SOON: Case studies of how teams use GH Packages.
An internal Artifactory instance is available if using the self-hosted runners. This is not always recommended as it has more awkward access requirements across the wider group, but there are cases where it the best choice.
COMING SOON: More details about why and when to use Artifactory.