== git hosting proposal ==
* adhere to git-flow for all the things. Automate said usage as far as possible.
{|- class="wikitable"
! colspan=4 | git-flow branching
|-
! Branch
! Environment
! Merge from
! Description
|-
| <code>master</code>
| production
| <code>release/</code> or <code>hotfix/</code>
| Released code with a <code>git tag</code> for each merge.
|-
| <code>release/v0.0.0</code>
| staging
| <code>develop</code>
| Contains final releasing work like updating versioning and changelog. This is where we keep semver concerns in check if they where not taken care of already.
|-
| <code>hotfix/v0.0.0</code>
| staging
| <code>master</code>
| Only for critically urgent fixes. In most cases doing a release from <code>develop</code> is preferred.
|-
| <code>develop</code>
| development
| <code>feature/</code> or <code>master</code>
| Only feature branches that are ready for production should get merged here. <code>master</code> gets merged here after each merge to it. Merging is done with pull requests and review.
|-
| <code>feature/featurename</code>
| development
| <code>develop</code>
| New features get implemented here until they are considered ready for production and merged to <code>develop</code>.
|-
| <code>support/v0.0.0</code>
| LTS
|
| Marked experimental in most implementations and unused for now.
|}
* Install gitlab on a vm and integrate external mirrors from github and ldap users from stoney-ldap.
** keep repo of public mirrors in hieradata so we can configure them from puppet.
** each organisation in stoney-ldap automatically gets a private project in gitlab.
* Configure web hook intrastructure and integrate with continuous integration system.
* Make continuous integration show feedback back in gitlab.
** check for <code>git annotate</code> support or use img badges.
'''On organization projects in gitlab'''
* Each project comes with default repos.
{| class="wikitable"
! Repo
! Description
|-
| <code>puppet</code>
| Set up using a template, contains a Puppetfile and Puppetfile.lock and a hieradata directory.
|-
| <code>role</code>
| Read only copy of global role module for reference.
|-
| <code>profile</code>
| Read only copy of global profile module for reference.
|}
* Everything in the latter two modules is configurable through hieradata in the first repo.
* The default setup automatically updates <code>role</code> and <code>profile</code> when they get new merges.
* A software agent (ci) regularly clones <code>develop</code>, does a full build and pushes the results back to <code>feature/tinderbox</code>
* This agent autmatically creates pull requests if tinderbox builds did not fail.
* Org leaders may then merge these PRs and bake them into a local release.
* Some kind of UI helps them do this without much technical knowledge.
* More repos may be added by the customer.
* project organizations are private, per customer.
== Links ==
* [http://gitlab.org/ gitlab] seems nice even though is is ruby on rails under the hood
* [https://github.com/sag47/gitlab-mirrors gitlab-mirrors] is a companion app to gitlab for adding readonly mirror repos to gitlab. We might consider hacking it to not use <code>git remote prune</code>.
* [http://www.javacodegeeks.com/2014/01/git-flow-with-jenkins-and-gitlab.html git-flow with jenkins and gitlab]
* [https://wiki.jenkins-ci.org/display/JENKINS/Gitlab+Hook+Plugin gitlab hook for jenkins]
= Links =