We, some of the ANZ open source engineers, have recently set up what we consider to be good engineering practises for our enterprise-backed open source project Sysl.
The following is a record of systems and practises we deem essential and the products and platforms we have chosen (in parenthesis):
- Open Source Licence included with source code (Apache License 2.0)
- Version control system (git & Github)
- (Write) access control (Github organisation & teams)
- One step build (GitHub Actions & GoReleaser)(
pip install pytest flake8 -e .Pysysl) - One step test (go test)(
pytestfor pysysl) - Continuous integration (GitHub Actions)
- Code reviews (Github Code Reviews)
- Automated release process (Specified master branch commit message triggers tag generation and CHANGELOG generation. Generated tags trigger deployment from CI systems. See the Releasing documentation for more details)
- Automated quality assurance (Pull requests are blocked until all checks pass)
- Issue tracking (Github Issue tracking with template)
- Project Management (Github projects)
- Documentation in same repository as source code (README and docs/ as starting point)
- Chat (Slack &
Gitter) - Status dashboard (Badges)
 The most involved pieces have been automated quality assurance and release automation. These parts of the Sysl project also keep evolving as we add new quality checks and artefact types. They deserve a closer look.
Our branch model is simple - we develop feature branches on our own forks and issue pull requests to master on anz-bank/sysl. As suggested by Github Flow, "There's only one rule: anything in the master branch is always deployable". Releases are linked to tags of commits in master on anz-bank/sysl.
Our original (upstream, parent) repository is owned by the Github organization anz-bank, which has a sysl-developer team. Only team members have write access to anz-bank/sysl and can merge pull requests into master. Additionally, the master branch of anz-bank/sysl is protected and has restrictions enabled to automate quality checks:
- Require pull request reviews before merging
- Dismiss stale pull request approvals when new commits are pushed
- Require review from Code Owners
- Require branches to be up to date before merging
- Require status checks to pass before merging
- Require passing tests and no linting warning (on GitHub Actions tests, GolangCI lint, deploy/netlify docs website)
- Require stable or improved codecoverage
- Require pull request reviews before publishing new version tag and release
 Happy coding and project setup!