Run .\build.cmd init
or .\build.sh init
to setup local environment.
The project is instrumented with common set of tasks implemented as targets via Nuke.Build. These can be invoked via entry point helper script build.cmd
(or one of the other extensions based on terminal of choice).
.\build.cmd <TARGET_NAME> --my-arg=<value>...
Common targets:
init
- initializes git repo, sets up versioning, and restores necessary cli tools. Installs .NET SDK if it's missingcompile
- compile the projectpublish
- .net publish the project, and package output into version stamped zip files intoartifacts
folderclean
- clear outbin
,obj
, andartifacts
folders
Additional build targets can be easily added by editing /build/Build.cs
The code uses GitFlow for branching and release workflow.
Latest active branch developers commit to is develop
, while main
represents current production code. Release branches are created during stabilization phase, and represent next release being reading to be shipped to production.
Versioning is derived from Git commit history using Nerdbank.Gitversioning. Current version can be obtained by running
dotnet nbgv get-version
When the team is ready to start preparing next release, they cut a release branch from the develop
branch. Release branch carries stabilization fixes for next release cycle, while develop
increments next major version number and starts accumulating new features.
Cutting a release branch can be done by issuing this command:
.\build.ps1 prepare-release
Builds created out of different branches will have the pre-release tags applied automatically to their version numbers:
develop
: <semver>-alpha
v.X.X
: <semver>-beta
main
: <semver>
any other: <semver>-<short-sha>
At the end of stabilization cycle when the release is made. The following steps should be performed:
- switch to release branch (ex. v2.0)
- edit
version.json
and change theversion
property to remove thebeta
tag - commit
- merge release branch into master
Config server allows configuration to be loaded from a dedicated service that is backed by one or more configuration sources. The default configuration source is git, allowing configuration changes to be stored in git, but loaded without having to redeploy the app.
The configuration is stored inside /config
folder in the repository. You can launch config server locally via docker-compose
from inside services
folder vas following:
services> docker-compose up configserver