3. Documentation

The Datagerry documentation is created using Sphinx.

3.1. Generation

In the case of a push or merge into one of the productive or development branches, the documentation is automatically generated via our continuous integration. Depending on the publication method, the documentation is then available as HTML source under /docs/_build/. Alternatively, the documentation can also be created manually using the included make file.

3.2. Approach

Since the documentation consists of pure HTML, it can be accessed directly via the index.html in the directory /docs/_build in a browser. Alternatively, the documentation is delivered for every running instance at https://yourdomain.com/docs/ .

2. GIT Repository — DATAGERRY feature-NET-1016_documentation-rest-object-routes-5b9d01e3973133d93a5602d741fb0fa256a1804b documentation

2. GIT Repository

The source code of DATAGERRY is managed in a GIT repository on GitHub:

2.1. Branches

We use several branches in our GIT repository:

development

The development of DATAGERRY is done in this branch. Every new feature, bugfix, … should be commited to that branch.

master

Branch with a stable version of DATAGERRY. All integration tests and CI should have been passed before merging the development branch into master. A merge of development to master will usually be done at the end of a sprint.

version-<version>

Version branches should be created for every minor version, e.g. version-1.2 or version-1.5. It should branch from master. For each released version (e.g. 1.2.1), a tag should be set on a version branch. Bugfixes can be added to a version branch to prepare for a new bugfix release (e.g. 1.2.2)

2.2. Creating a Release

Releases should be versioned using Semantic Versioning.

To create a release, do the following steps:

  1. create a version-<minorversion> (e.g. version-1.2) branch from master

  2. set a tag with the full version number (e.g. 1.2.1) on the last commit on that branch

To create a bugfix release of an existing version, do the following steps:

  1. merge bugfixes in an exitsing version-<minorversion> branch

  2. set a tag with the full version number (e.g. 1.2.1) on the last commit on that branch

A tag should be set by creating a release in the GitHub WebUI. Github Actions release workflow will start automatically after setting a new release and will create binaries, Docker images and documentation.