Git, Git Flow, and Git Hub:
In DevOps, all GItHub repositories and CI processes are managed using GitFlow. More information about GitFlow can be found here:
When working in any of the common DevOps repos (typically prefixed with BSS-DevOps) in GitHub, Git Flow must first be initialized usinig:
git flow init
Accept all of the defaults and use git status to ensure you are working in the local develop branch. Git Flow uses the following concepts:
Features – These get merged into the develop branch as completed. A combination of features will become a release. We name these with feature-name
Releases – These eventually get merged into both the develop and master branch and will typically be a combination of features. However, when you are the only one working on the repo, it can be “fast tracked” so you can solely use releases. We name these with the version-name.
Hot fixes – These are to fix changes that break production and get merged directly into the master branch.
When starting a feature or release, use the command:
git flow release start version-number
git flow feature start jira-ticket-number
This will break off a new branch from development locally to begin your development against it. From here use the git add and git commit commands as normal. No need to push since development occurs locally. Make sure all files such as package.json,package.json.lock, CHANGELOG.md and README.md are updated accordingly. The CHANGELOG.md file should include all changes being performed in the feature or release. A release will typically list multiple features in the versions outlined as releases in the CHANGELOG.
When done, use:
git flow release finish version-number
git flow feature finish jira-ticket-number
From here the changes will be merged to the local develop branch. If performing a feature, only push to the develop branch. If performing a release, push to develop and master branches in the remote Git repository:
git push origin develop
git push origin master
git push --tags
Any version tags specified should match the information in the CHANGELOG.md.
Once tags and changes have been pushed to the remote repository in GitHub, go to the releases in the GitHub web interface. From here create a new release, associate it with the proper version tag, and copy the fix and feature lists from the CHANGELOG.
Pushing to NPM
Node.js and NPM is used by the DevOps team to manage the BSS CLI and other tools. All DevOps employees should be owners for the BSS CLI tool in Stansberry Research org. As an owner, updates to the tool can be published. From the BSS CLI repo, this can be done using:
npm run deploy
This command will do the following:
npm run build – Performs rm -rf dist/ && tsc && bash non-typescript.sh (remove dist directory, runs TypeScript to leverage the tsconfiig.json settings, and runs specific non-typescipt shell script commands).
cd dist && npm install –production – Goes into the new dist/ directory created from TypeScript in the previous command and installs production needed modules.
npm publish && cd .. – Publishes the compiled JS code in the dist directory and goes back to the main repo directory.