This post is part one in a series of posts
Following the recent acquisition of my former company Over.ai by Vonage lots of changes and demands came up, some for better automation, other is to use the company cloud provider("aws"), better security and monitoring.
Then I decided to create the ultimate enterprise grade, battle tested, aws based CI/CD pipeline for our entire frontend applications, let's start with the methodology I've decided to work with.
Git Flow
Git-flow is a branching model and release management strategy for Git. It defines a well-formulated path for a project’s development life cycle and ensures that the development team adheres to the processes. It offers a set of extensions over Git to provide a high-level repository operation.
Local
Using git pre commit hook with husky to run several tools making sure the code base is linted in the same manner, commit messages are using the conventional-commits standard and removing unused and unreachable code.
E.g. using tslint for linting, commitizen for conventional commits, etc…
.cz-config.js (commitizen cz-customizable)
Master
Contains production code. Each commit to the master will have special process of bumping the application version, generating a changelog automatically and adding a tag to the commit using semantic-release.
.releaserc
Develop
Contains the latest development changes that will be included in the next release.
Feature/*
A new branch is created for each new feature we work on.
We start if from develop and once we’re done, merge back into it.
Release/QA
Starts from develop and signifies that there will be a new release once we merge this branch into master.
Hotfix/*
Starts from master and merges into both master and develop.
Used when we need to deliver urgent changes to our production app but develop is not yet ready to produce a release branch.
All of the following branches will run automated tests, the release branch will be manually tested and checked.
Master, Release and Develop branches will be locked for direct code commits and only pull requests will be merged into them after a code review and making sure all unit and e2e tests are passing.
Every single one of those branches will spin up a preview application with a unique url and that will happen automatically of course, using the AWS Amplify.
AWS Amplify Console
The AWS Amplify Console provides a Git-based workflow for deploying and hosting fullstack serverless web applications. A fullstack serverless app consists of a backend built with cloud resources such as GraphQL or REST APIs, file and data storage, and a frontend built with single page application frameworks such as React, Angular, Vue, or Gatsby.
Amplify bring the following features out of the box and with a simple configuration:
- Branch Detection using a regex
- View test results in Amplify console directly.
- Easy domain setup especially when using Route53.
- Application are deployed to AWS CloudFront CDN and globally available.
- Preview application for every branch configured, either using a specific subdomain or a unique url auto generated.
- Password protection for preview application.
- Setup alarms and notification using cloudwatch and amplify console.
Cypress test results shown in the amplify console, with links to recorded e2e video's for each test.
Amplify configuration can be handled in the project itself with an amplify.yml file, with a CLI or directly on the console.
amplify.yml
References:
https://nvie.com/posts/a-successful-git-branching-model/
https://aws.amazon.com/amplify/console/
Recommended Packages:
https://www.npmjs.com/package/husky
https://github.com/conventional-changelog/commitlint#readme
https://github.com/commitizen/cz-cli
https://github.com/palantir/tslint / https://github.com/eslint/eslint
Thank you very much for reading this post, in the next following posts I will show how to add visual regression snapshots as part of our testing suite and snyk to monitor dependencies in our production application and to test each pull request.
Top comments (0)