Skip to content

Developer

Jump to bottom
Tim Long edited this page Dec 17, 2020 · 1 revision

Developer Information

We welcome community involvement and appreciate pull requests.

Build Status

Build Status (click for details)

We use a TeamCity build server that will automatically build and test all commits. Builds are run on Ubuntu Linux as a check for cross-platform integrity.

Branching Strategy

Tigra Astronomy uses the Git Flow branching strategy. You don't have to but it is really simple and you might like it. At minimum, what you need to know is:

  • Contributions go on the develop branch via pull request.
  • master is reserved for production releases.

Within that, work however you like, but prefer small self-contained feature branches where possible.

Versioning

We follow the rules of Semantic Versioning and code is typically versioned automatically as part of the build process. All code that was not built on the master branch must have a prerelease tag. This normally happens automatically.

NuGet Packages

We ask that you do not directly distribute NuGet packages. Instead, users can get packages from one of the following feeds:

Integration Builds: http://teamcity.tigra-astronomy.com:8111/guestAuth/app/nuget/feed/TigraOss/TigraOSS/v3/index.json Public betas and releases: https://www.myget.org/F/tigra-astronomy/api/v3/index.json

Final releases are promoted to the official public repository at nuget.org.

General Suggestions

  • Where possible, always work against an issue in the issue tracker (create one if you need to), so that everyone has visibility of what's being worked on and by whom.

  • Consider creating a draft pull request as soon as you create your feature branch, as once again it helps with visibility and our build server will be able to pick up your commits and run the unit test suite against them.

  • Target your pull requests to the develop branch (not master). In Git Flow, master is reserved for production releases.

  • Pull request are open to code review by other contributors, try to get into the mindset where you welcome this rather than fearing it. When reviewing other developers' code, try to avoid "nit picking" about things like formatting and focus on substance.

  • Before a pull request can be merged, it must have a clean build, pass all unit tests and have sign-off from at least one other developer.

  • We strongly encourage test-first development. Our unit test suite uses the Machine.Specifications framework, but we appreciate this can seem a bit alien to some people so you may use xunit if you prefer. If you can't write tests first, write them second. And if you can't write them second, expect to get some push-back. Any test runner of your choice is fine, be we highly recommend NCrunch if you can justify the purchase. Our build server is the final arbiter of whether a test passes or fails.

  • Try to write Clean Code. Readability is valued higher than compactness or performance.

  • Try to make code self-documenting where possible. Public surface APIs should have XML documentation comments as this is used to generate Intellisense and will help other developers a great deal.

Clone this wiki locally