Skip to content

GitLab

Last edited by Gualter
Page history

gitWorkflows

This page is a work-in-progress towards the definition of standard development and deployment workflows for Ecobytes projects. It is focused on the use of git, lab and dokku.

Get the project repository

Setup upstreams

These show the upstreams used currently on this documentation

$ git remote -v
dokku	dokku@apps.ecobytes.net:frab (fetch)
dokku	dokku@apps.ecobytes.net:frab (push)
origin	https://lab.allmende.io/ecobytes/dbp2016.git (fetch)
origin	https://lab.allmende.io/ecobytes/dbp2016.git (push)

dev-stage-live workflow

This is a proposal for improving deployment workflows and would require each project to run three dokku instances.

  • origin for lab.allmende.io
  • dev for apps.ecobytes.net:app-dev
  • stage for apps.ecobytes.net:app-stage
  • live for apps.ecobytes.net:app-live

TODO: complete this with proper commands and a good log of git remote -v

Use deployment branch

Between releases, code to be deployed in testing instances should always be merged on deployment

DISCUSS: should we rather have dev, stage and live branches, which are always deployable on respective dokku instances (see above)?

Checkout deployment to the local machine

Assuming you have set the lab.allmende.io upstream as origin, run:

git checkout -b deployment origin/deployment

You should see:

Branch deployment set up to track remote branch deployment from origin.
Switched to a new branch 'deployment'

Merging into deployment

It is recommended to branch during feature development. Branches should ideally relate to the issue or story being addressed, e.g. is49 for patches to address issue #49 (closed) or us35 to address user story #35 (closed) (on taiga).

Assuming that you kept the upstream and local in sync, you can opt to:

  1. merge on lab by issuing a merge request
  2. merge locally

Merge on lab

Push your branch to lab:

git push --set-upstream origin is49

Then:

  1. Go to the activity stream
  2. Click on link to issue merge request
  3. Select deployment instead of master for comparing branches
  4. Merge them, if there are no conflicts (otherwise check below)

Note: once the issue is successfully fixed or the story completed (and tested) it is safe to delete the originating branch

And finally don't forget to keep your local repository in sync:

git checkout deployment
git pull

Merge locally

git checkout deployment
git merge is49

And to keep the lab repository up-to-date:

git push

Dealing with conflicts

If the code has meanwhile been changed by commits merged into the branch later than when you fetched it, it is probably that a merge conflict occurs. A conflict needs to be manually solved locally.

Check out where are the conflicting files:

git status -v

Edit the file(s) with your favorite text editor or IDE.

Do you see these lines?

<<<<<<< HEAD
=======
>>>>>>> lab/is49

Everything between << == >> needs to be manually resolved. Please note that

=== is the mirror line
=== and >>> are both the ends of the corrupted blocks.

Once you are done inspecting the file logic and merging everything coherently, do:

git add [Alt + .]
git commit
git push

Launch the deployment magic!

As you have your new commit, just do:

git push dokku deployment:master

This is pushing the deployment branch to dokku remote master, as it only recognizes master branches.

Then watch the magic happen and after some time the instance will have been updated.

TODO: merge last section of the deployment wiki page