Automatic Application Versioning

#webdev #productivity #devops #tutorial

Learn how to setup versioning with in your CI/CD workflow

Benefits

Easy rollback to last working release
Automatic release workflow

Setup

npm install @changesets/cli && npx changeset init

Make sure your package.json includes the version field i.e version: "0.0.0" and private: true.

Then set privatePackages to { version: true, tag: true } in your .changesets/config.json

To create a version bump

npx changeset

which should prompt you to specify the type of change

patch - when you fix issues with an exiting release
minor - when you modify features that do not impact application function
major - when you've made changes that add new features or change exiting application functionality

See here for more information on semantic versioning

You'll then be prompted to provide a message for the change.

To create a new version

npx changeset version

To publish the new version

npx changeset publish

Release setup

We'll use the changeset github action. I'll be using firebase for hosting in this example.

Github action

name: Release to Firebase
"on":
  push:
    branches:
      - master
jobs:
  build_and_deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3

      - name: Install dependencies
        uses: ./.github/actions/setup

      # run tests before release
      - run: pnpm test

      - name: create release pull request
        id: changesets
        uses: changesets/action@v1
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

      # This step can be replace with your build script i.e `npm run build`, then push to your hosting provider
      - uses: FirebaseExtended/action-hosting-deploy@v0
        # only create a release to firebase if we have changes
        if: steps.changesets.outputs.hasChangesets == 'true'
        env:
          FIREBASE_CLI_EXPERIMENTS: webframeworks
        with:
          repoToken: "${{ secrets.GITHUB_TOKEN }}"
          firebaseServiceAccount: "${{ secrets.FIREBASE_SERVICE_ACCOUNT }}"
          channelId: live
          projectId: <project-id>

This step does the following:

triggers your github action when you merge to master
creates a release PR based on your changesets, which when merged pushes to your desired hosting provider
then creates a tag that's pushed to github.