v2 of the Rules.
This is a Gatsby generated site pulling data from:
- Install nodejs version specified in
.nvmrc
(Ideally usenvm
to use the right version) - Ensure corepack is enabled -
corepack enable
(this allows auto-install of the correctyarn
version)
- Clone the repo from https://github.com/SSWConsulting/SSW.Rules
- Run
yarn install
to install packages - Create environment files (.env.development) based off
.env.template
- get the values from Keeper (SSW.Rules Environment Variables)
Note
If you don't work at SSW or can't get on to the SSW.Rules team you can just add values to GITHUB_API_PAT and CONTENT_BRANCH
ForGITHUB_API_PAT
, create a PAT on GitHub (remove angle brackets <>)
SetCONTENT_BRANCH
tosample-content-with-guid
(its a smaller version of the main content branch which will build much quicker 🙂) Sometimes you might want to usemain
or create your own branch if you are testing something.
- Branch off main for your PBI
- Install the recommended extensions if using VS Code
- Do your work
- Run the site in development mode by
yarn dev
(.env.development is required for this step) it takes a while to build all the rules If you have issues, runyarn clean
thenyarn dev
- Commit code and push
- Raise a PR
- Get it merged!
Figure: VS Code recommended extensions notification
- Code Compiles
- Check the Acceptance Criteria.
- Code is squash-merged to main via a pull request that was approved by a 2nd developer.
- Another team member agrees it’s ready for Production.
- Pushed to Production.
- Use @Mention (OR Send email) to notify Product Owner/PBI stakeholder that PBI is done (be sure to include screenshots/done video as proof)
<As per rule: Done - Do you go beyond 'Done' and follow a 'Definition of Done'?>
- Branching strategy is based off Release Flow
main
is the main 'dev' branchrelease/xx
is the 'production' one (where xx is the Sprint number)- Always create a new branch for your PBIs
- Always delete your branch once your PR has been merged
-
Changes made to http://github.com/SSWConsulting/SSW.Rules.Content (i.e. rule changes) trigger builds that deploy:
- main to the staging site: https://tfs365.com/rules or check the latest staging workflow for the url
- latest release/xx to the production site: https://www.ssw.com.au/rules
-
Branching off main to release/xx, or making changes to release/xx will build and deploy to the production site: https://www.ssw.com.au/rules
Rules repository lives here: https://github.com/SSWConsulting/SSW.Rules.Content
Merging changes to main on this repo will trigger:
- a build/release of the main branch in Staging [(https://staging.ssw.com.au/rules/)](https://tfs365.com/rules or check the latest staging workflow for the url).
- a build/release of the release branch Production (https://www.ssw.com.au/rules)
- An example rule is provided in the repo under
http://localhost:{{ PORT NUMBER }}/rule/
- This example rules shows all the different components that can be used e.g. headings, lists, boxes, etc.
Figure: Sample of the Example Rule
Sometimes you might have to update a rule markdown file to test your latest feature, such as changing the background color of a greybox. To update specific markdown components, follow these steps:
- Access the
sample-content
branch:
- Visit SSW.Rules.Content
- Switch to the
sample-content
branch.
- Edit the Rule:
- Locate the rule you want to modify in the
sample-content
branch.
- Test Your Changes Locally:
- Open your local instance of SSW.Rules, usually in VS Code.
- Build the project using the following commands:
yarn clean
and thenyarn dev
- Open your local instance in your browser and navigate to the edited rule to see your changes.