Deploying your changes

Now with these tasks completed:

  • initialized and configured projen
  • scaffolded the new project
  • synthesized a new construct
  • placed source code in the /src directory to give it functionality
  • built the project

We now need to understand how to safely and efficiently deploy the changes to our remote repo.

Git

We want to isolate our changes to their own unique branch

This tutorial assumes you are already familiar with Git and its benefits, if not, a good starting point would be the

Commit your code using conventional commits ensuring they are prefixed by one of the following:

Conventional commit prefix Description Example - Current version New version
chore a commit of this type is used for changes to build files 1.2.1 1.2.1
fix a commit of this type patches a bug in your codebase 1.2.1 1.2.2
feat a commit of this type introduces a new feature to the codebase 1.2.1 1.3
other are available and can also be used. See .versionrc.json for full list

It is worth noting that if you are planning to commit changes here or elsewhere as part of a ticket, the STRY number should be included in the commit message. For instance on the ServiceNow board, if you worked on a change as part of STRY0037421, where you implemented a new feature, your commit message should look like:

“feat(STRY0037421): Implemented [YOUR NEW FEATURE]”

feature release - Git process

The following series of images displays the process of how a feature release might look.

asdf
1: The target repo on the remote, with only a single commit to it

asdf
2: A local clone of the remote repo is made

asdf
3: A branch named “feature” is made in the local repo.

Worth noting however is that a new commit has been made to the remote repo, presumably by another developer
asdf
4: Three commits are made to the feature branch

asdf
5: The feature branch is squashed using an interactive Rebase, condensing all commits of the branch into a single commit

asdf
6: The resulting commit with a new hash

asdf
7: The HEAD is moved back on to the main branch, and changes from the remote repos main branch are pulled into our local main branch

asdf
8: The feature branch is rebased onto the main branch, giving it a consistent, linear history with the additional commit from the remote, and allowing a fast-forward merge of the feature branch when pushed

asdf
9: The local feature branch is pushed to the remote

asdf
10: A pull request is made through BitBucket’s GUI, requesting the feature branch be pulled into the main branch of the remote

asdf
11: If accepted, a fast-forward merge will occur, merging in the feature branch into the main branch with a linear history

asdf
12: Like before, The HEAD is moved back on to the main branch, and changes from the remote repos main branch are pulled into our local main branch

asdf
13: A release is commenced from the local repo, creating a new version commit, which is then pushed to the remote

npm run release

npm run release creates a new release, in doing so it will:

  • Bump the version in package.json
  • Output all correctly formatted commit comments since the last release to CHANGELOG.md
  • Commit the changed files and tag the release using the new version
  • Triggering the publisher pipeline again, but this time it will publish the new version to the CodeArtifact repository and subsequently to ConstructHub

End Module