How to Automate Project Versioning and Releases with Continuous Deployment

Using semantic version control can make it easier to maintain and communicate software changes, but manual operations are cumbersome. Even if you manually merge PR, mark the submission and push the release, you still need to write a release description. There are many steps, high repetition, time-consuming and labor-intensive.

This article will explain how to achieve more efficient processes and fully automate release processes by integrating semantic versioning into the continuous deployment process.

Semantic version control

A semantic version is a version number consisting of three numbers, such as 1.4.10. Each number has a specific meaning:

Major version changes (Major)

The first number indicates a major version change, meaning there is a destructive change.

Minor version changes (Minor)

The second number indicates a minor version change, meaning that new features have been added.

Patch version change

The third number indicates a patched version change, which means a bug is fixed.

The semantic version can be understood more concisely as: destructive changes, functional changes, and bug fixes. This description is more precise and avoids ambiguity.

Submit information format

To ensure that the semantic version number is correctly incremented and the correct version is released, a standardized submission information format is required. A standardized submission information format helps determine when to increment which number and easily generate publishing instructions. Here, Angular will be used to submit information conventions, and of course it can also be changed as needed.

The format is as follows:

<code></code>

Each submission contains the title , body , and footnote .

Submit title

The title is a must, it has a special format including type , optional scope and topic .

The title type is a required field to illustrate the impact of the submission on the next version. It must be one of the following types:

• feat : New features
• fix : bug fix
• docs : Document changes
• style : Changes that do not affect the meaning of the code (for example: spaces, formats, missing semicolons, etc.)
• Refactor : Code refactoring, neither fixing bugs nor adding functions
• perf : Performance improvements
• test : Add or correct test
• chore : Changes to build processes or auxiliary tools and libraries, such as generating documents

A scope is a grouping property that specifies subsystems that submit related to subsystems, such as APIs, application dashboards, or user accounts, etc. If multiple subsystems are modified by the commit, an asterisk (*) can be used instead.

The title topic should briefly describe the changes made. The following rules are required when writing a topic:

• Use imperative sentences, present tense (e.g., "changed" instead of "changed" or "changed").
• Lowercase of the initial letter.
• No period (.) is added at the end.
• Avoid topic lengths exceeding 80 characters. Submit the body.

Like the title theme, the main text should also use imperative sentences, present tense. It should include the motivation for the change and compare it to previous behavior.

Submit footnotes

The footnote should contain any information about the destructive changes and is also where the question cited for this submission is closed.

Destructive change information should start with BREAKING CHANGE: followed by a space or two new lines. The remaining submission information is here.

Enforce submission information format

In teamwork, standardizing anything that everyone needs to follow is always a challenge. To make sure everyone uses the same submission criteria, we will use Commitizen.

Commitizen is a command line tool that simplifies the process of using a consistent commit message format. Making the repository compatible with Commitizen means that anyone on the team can run git cz and get detailed prompts to fill in the submission information.

Generate and publish

Now that we know that our submissions follow consistent standards, we can start generating releases and release notes. To do this, we will use a package called semantic-release. This is a well-maintained package with good support for a variety of Continuous Integration (CI) platforms.

semantic-release is key to our journey, as it will perform all the steps required for release, including:

1. Confirm the last version you released
2. Determine the publish type based on the submissions added since the last release
3. Generate publish instructions for submissions added since the last release
4. Update the package.json file and create a Git tag corresponding to the newly released version
5. Push new version

Any CI is OK. In this article, we use GitHub Action because I like to use the existing features of the platform before seeking a third-party solution.

There are many ways to install semantic-release, but we will use semantic-release-cli because it provides step-by-step operations. Let's run npx semantic-release-cli setup in the terminal and fill in the interactive wizard.

The script will do the following:

• Run npm adduser with the provided NPM information to generate .npmrc.
• Create a GitHub personal access token.
• Update package.json.

Once the CLI is finished, it adds semantic-release to package.json, but it won't actually install it. Run npm install to install it and other project dependencies.

The only thing left is to configure CI through GitHub Actions. We need to manually add a workflow that will run semantic-release. Let's create a publishing workflow in .github/workflows/release.yml.

 <code>name: Release on: push: branches: - main jobs: release: name: Release runs-on: ubuntu-18.04 steps: - name: Checkout uses: actions/checkout@v2 - name: Setup Node.js uses: actions/setup-node@v1 with: node-version: 12 - name: Install dependencies run: npm ci - name: Release env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} # If you need an NPM release, you can add the NPM_TOKEN # NPM_TOKEN: ${{ secrets.NPM_TOKEN }} run: npm run release</code>

Steffen Brewersdorff has done a great job of introducing CI with GitHub Actions, but let's briefly review what's going on here.

This will wait for a push to the main branch to occur before the pipeline is run. You can change this setting as you like to run on one, two, or all branches.

 <code>on: push: branches: - main</code>

It then uses checkout to pull the repository and install Node so that npm can be used to install project dependencies. If this is something you prefer, you can add a test step.

 <code>- name: Checkout uses: actions/checkout@v2 - name: Setup Node.js uses: actions/setup-node@v1 with: node-version: 12 - name: Install dependencies run: npm ci # You can add a test step here # - name: Run Tests # run: npm test</code>

Finally, let semantic-release do all the magical operations:

 <code>- name: Release run: npm run release</code>

Push changes and view actions:

Now, each time a specified branch is committed (or merged), the operation is run and published with a release note.

Post a party!

We have successfully created a CI/CD semantic release workflow! Isn't it that painful? The setup is relatively simple, and there are no disadvantages to having a semantic publishing workflow. It just makes tracking changes much easier.

semantic-release There are many plug-ins that can enable more advanced automation. For example, there is even a Slack release bot that can be published to the project channel after the project is successfully deployed. No need to go to GitHub to find updates!

The above is the detailed content of How to Automate Project Versioning and Releases with Continuous Deployment. For more information, please follow other related articles on the PHP Chinese website!