Skip to content

Latest commit

 

History

History
88 lines (62 loc) · 3.92 KB

DEVELOPERS.md

File metadata and controls

88 lines (62 loc) · 3.92 KB
Raw

Introduction

This document aims to collect the guidelines for the development of MiCADO. This should be treated as an evolving document.

Coding Style

  • Python: PEP-8 [4]
  • YAML: 4 Space indent

Versioning

We adapted semantic versioning 2.0.0 [3]. This infers the following renaming of previous releases:

  • V3 -> 0.3.0 (further modifications will result in 0.3.1, 0.3.2, etc.)
  • V4 -> 0.4.0

Previous releases (V1 and V2) should remain untouched.

Repositories

We should use separate GIT repositories for each separate logical unit within the micado-scale github.com organization as follows:

  1. Each component should be placed in its own repository with the prefix component-, e.g., component-alert_manager.
  2. The micado repository is the main repository, containing "glue" files (e.g., cloud-init and/or docker-compose related ones).
  3. Documentation should go into the docs repository in either markdown or restructured text format.

Each repository should contain a README.md file explaining the purpose of the repository, basic functionality, and pointers for further documentation (in the docs repository).

The master branch of each repository should contain an ISSUE_TEMPLATE.md for issue reporting. This should be copied over from the master branch of the micado repository.

Branching

We adapt the successful GIT branching method [1] with the following modifications:

  1. The master branch should always represent the latest stable release.
  2. develop branch is for development.
  3. In each repository, from its develop branch, for each major release, a release branch should be created.
  4. Release branches should be named based on their major and minor versions: v_MAJOR_.MINOR.x
    • E.g., for the 0.4 releases, the branch should be called 0.4.x (x is literal, represents that all 0.4 releases, e.g., 0.4.0, 0.4.1, etc. are based on this branch).

Releases

For 0.4.0 and 0.3.0 we should use the following procedures, as 0.4.0 is considered a new implementation, but 0.3.x requires fixes and refactoring.

For the current (0.4.x) release branch:

  1. Merge the release branch to develop in each affected repository.
  2. Merge the release branch to master.
  3. Create tag with the release number (e.g., 0.4.0).

For the 0.3.x release branch:

  1. Create a tag on the release branch (no merging with develop branch, but selected fixes can be added).

Commit Guidelines

We adopt the angular.js commit guidelines [2] with some modifications. We do not pre-define scopes. The scope part should describe the affected part in the commit message.

Dev Docker registry

We use a private docker registry to develop MiCADO components. This registry is running on CloudSigma and protected with basic authentication.

  • The address of the registry: cola-registry.lpds.sztaki.hu

  • To get access, contact with DevNull group (devnull@lists.lpds.sztaki.hu) at SZTAKI.

  • The naming convention in the registry: username/imagename:version

  • Push image to the registry:

    docker login cola-registry.lpds.sztaki.hu
docker push cola-registry.lpds.sztaki.hu/username/imagename:version

  • To use the registry during the development:

    1. Replace the default image name with dev image name
    2. Insert this into the cloud-init file: 
      docker login -u username -p password cola-registry.lpds.sztaki.hu

  • To create docker service with private registry authentication:

    docker service create --with-registry-auth image_name

  • To create docker stack with private registry authentication:

    docker stack deploy --with-registry-auth -c docker-compose.yml stack_name