Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
H
hivemind
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 46
    • Issues 46
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 10
    • Merge Requests 10
  • Operations
    • Operations
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
  • hive
  • hivemind
  • Wiki
  • Home

Last edited by Dariusz Kędzierski Nov 19, 2020
Page history

Home

General notes on hivemind development process

Branching methodology

Hivemind is being developed using a master/develop branching process. Production builds should always be made from the master branch, and only production fixes should be merged to the master branch except when an official release is ready. Normal development changes should be merged to the develop branch. We are using this process to enable fixes to be made to production systems without requiring the production fixes to reside in branches.

A side-effect of this is that someone should always be able to build a production node using the head of the master branch.

If you plan to commit your own remote branches to the repo (if you're working for more than a day or two in a branch, this is recommended), please add a prefix with your initials, so that a casual viewer of the branches list can see who is responsible for the branch.

Coding conventions

  • 2 space indention (DO NOT USE TABS)
  • Avoid the use of acronyms and abbreviations in source code (i.e. in variable names) and file names unless it is standard abbreviation/acronym of the English language.

Testing procedure

Testing procedure is described in document:

  • testing using full local stack: https://gitlab.syncad.com/hive/hivemind/-/wikis/Testing-hivemind
  • testing using dockerized hived node: https://gitlab.syncad.com/hive/hivemind/-/wikis/Testing-hivemind-using-docker-images
Clone repository
  • Continuous Integration design principles
  • Drop and recreate dependencies when you want to alter table or view in Postgresql
  • Testing hivemind using docker images
  • Testing hivemind
  • Home