Community mailing list archives

community@mail.odoo.com

Re: Gitflow BangBang

by
dar
- 02/06/2015 01:24:42
@Lionel: 

Your design seems quite complex. Maybe you aren't using protected branches?

I would architect arround the git flow default: master and development branches, which are dynamically complemented by feature, support, hotfix and release brnaches. your alpha/beta stream maps to release branches, your production stream matches the master branch and your team streeam matches the development branch.

Pleas note that the configuration of this can be on a per branch level as .gitflow file can be verion controlled. You'd have to make sure, that gitflow files dont get altered, by excluding them completely in the gitignore, and keep an eye on them in merges.

As I see it's a rather trivial design then with two upstreams (backports and odoo) and one origin (team).
After configuring your master and development branches, which can be nested, so in the case of odoo, it would look like:
v8: master: 8.0 development: 8.0-dev
v7: master: 8.0 development: 8.0-dev

So your local workflow would go like this:
git alias_change_upstream && git flow feature start (to set the right upstream together wirth the right development branch)
git alias_change_upstream && git flow feature finish

however, I would not use multiple upstreams on your local machine, but rather merge upstream changes on a regular basis into your development branch. It's like upstream would be an additional team member hacking on your dev branch... (or two, when you include backports), then your master branch (as per version branch) would be equal prodution, and you would just init alpha/beta ("release") branches with the git flow release start command.

IMHO, it's quite straight forward, this way. The key is protected branches, tough -> gitlab with github replay?

I'm eager to hear your comments!

Saludos Cordiales
David Arnold

David Arnold BA HSG / Analista
315 304 13 68/ dar@devco.co

devCO - empresa de consultoría de sistemas (en fundación)
http://www.devco.co

This e-mail message may contain confidential or legally privileged information and is intended only for the use of the intended recipient(s). Any unauthorized disclosure, dissemination, distribution, copying or the taking of any action in reliance on the information herein is prohibited. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, or contain viruses. Anyone who communicates with us by e-mail is deemed to have accepted these risks. devCO is not responsible for errors or omissions in this message and denies any responsibility for any damage arising from the use of e-mail. Any opinion and other statement contained in this message and any attachment are solely those of the author and do not necessarily represent those of the company.


2015-02-06 0:36 GMT-05:00 David Arnold <dar@devco.co>:
So the key thin, I found out is to include a tracked branch-based .gitconfig file into the (trusted!) repo:
So from within the repo, this amounts to:

git config --add include.path ../.gitconfig

Then we can populate .gitconfig by convention and set up a standard configuration with different upstremas... Once I got something ready, I'll share it here to get feedback.

Saludos Cordiales
David Arnold

David Arnold BA HSG / Analista
315 304 13 68/ dar@devco.co

devCO - empresa de consultoría de sistemas (en fundación)
http://www.devco.co

This e-mail message may contain confidential or legally privileged information and is intended only for the use of the intended recipient(s). Any unauthorized disclosure, dissemination, distribution, copying or the taking of any action in reliance on the information herein is prohibited. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, or contain viruses. Anyone who communicates with us by e-mail is deemed to have accepted these risks. devCO is not responsible for errors or omissions in this message and denies any responsibility for any damage arising from the use of e-mail. Any opinion and other statement contained in this message and any attachment are solely those of the author and do not necessarily represent those of the company.


2015-02-05 7:53 GMT-05:00 David Arnold <dar@devco.co>:

I've checked again the sources and indeed an origin / upstream switch can be accomplished by aliasing:

PSEUDOCODE

git oca = git config gitflow.origin oca
git odoo = git config gitflow.origin odoo
git ours = git config gitflow.origin origin

​Just wanted to substanciate further, to keep the discussion focused.​

Saludos Cordiales
David Arnold

David Arnold BA HSG / Analista
315 304 13 68/ dar@devco.co

devCO - empresa de consultoría de sistemas (en fundación)
http://www.devco.co

This e-mail message may contain confidential or legally privileged information and is intended only for the use of the intended recipient(s). Any unauthorized disclosure, dissemination, distribution, copying or the taking of any action in reliance on the information herein is prohibited. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, or contain viruses. Anyone who communicates with us by e-mail is deemed to have accepted these risks. devCO is not responsible for errors or omissions in this message and denies any responsibility for any damage arising from the use of e-mail. Any opinion and other statement contained in this message and any attachment are solely those of the author and do not necessarily represent those of the company.


2015-02-05 7:42 GMT-05:00 David Arnold <dar@devco.co>:

Hi,
The git workflow on any non-trivial Odoo project is much more complex
that gitflow.
You'll manage feature branches and hotfixes like gitflow but:
- on multiple projects (odoo, OCA, custom...)
Have you thought about the idea of storing the git-flow tool config on a branch level in the .gitconfig file (as shown in the example provided in the first post)? I think this takes down this one entire degree of complexity, as it's up to the branch "owner" to manage the default gitflow via this file 
- using multiple upstreams (Odoo/OCB)
here i might see the gitflow tool only support one upstream, BUT, there is aliasing fallback on top of normal git commands (would be at home also in .gitconfig). Can this be a solution to manage this complexity dimension?
- using multiple bugtrackers (githbub, Odoo SA's ticket system, your
internal ticket system)
I'm not sure if this touches the scope of the proposal. I don't think so. (is reply to Andreas, too ;)
- targetting several Odoo versions (the one you deployed, the latest
official odoo, master)
I see that, and here it get's interesting. I havn't been able to fully investigate git flow support command. master by design is the deployable version in a typical continous deployment setup, versions are managed by release tags. Odoo does it somewhat the other way round. GRRRRR ;) You could always start a hotfix path from any past commit (an therefore release tag). ON the other hand, .gitconfig comes in handy, because you can configure master develop branch on a version-branch basis. every fork from the verion brnach would maintain this version branch setting. so hirachry over the branch space is possible...
- on multiple servers (your station, your internal git server, github,
this is the counterpart of multiple upstream problematic -> multiple downstream and could be adressed in a parallel way. 
 
So if you mix this all you get a big headache and a very specific workflow.
I hope we can alleviate this with some pure and disciplined reasoning exercise. 
I've intended to write a comprehensive blog post on the topic for quite
some time, I'll try to write it down once and for all.
Here's as attachment a diagram of what our own git workflow looks like.
Of course, we've scripted a lot of it to make it bearable.

Anyhow, I'd love to push the edges and are eager to hear your further comments.

@Andreas, I think indeed, integration into bug trackers is not of primary concern, although it would be nice though. git flow tooling is open source, so it definitively would be possible to script some ecosystem specific glue code... I'm not a fan of runbot, because its an app (odoo) specific monolithic solution. We are adopting drone.io and it's a bliss, as staging and production is just a matter of how you tag your build artefacts. And I hope odoo does not follow of this statement that we need a odoo module for odoo deployments.. ;)

Saludos Cordiales
David Arnold

David Arnold BA HSG / Analista
315 304 13 68/ dar@devco.co

devCO - empresa de consultoría de sistemas (en fundación)
http://www.devco.co

This e-mail message may contain confidential or legally privileged information and is intended only for the use of the intended recipient(s). Any unauthorized disclosure, dissemination, distribution, copying or the taking of any action in reliance on the information herein is prohibited. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, or contain viruses. Anyone who communicates with us by e-mail is deemed to have accepted these risks. devCO is not responsible for errors or omissions in this message and denies any responsibility for any damage arising from the use of e-mail. Any opinion and other statement contained in this message and any attachment are solely those of the author and do not necessarily represent those of the company.


2015-02-05 7:22 GMT-05:00 Lionel Sausin <ls@numerigraphe.com>:

Hi,
The git workflow on any non-trivial Odoo project is much more complex 
that gitflow.
You'll manage feature branches and hotfixes like gitflow but:
- on multiple projects (odoo, OCA, custom...)
- using multiple upstreams (Odoo/OCB)
- using multiple bugtrackers (githbub, Odoo SA's ticket system, your 
internal ticket system)
- targetting several Odoo versions (the one you deployed, the latest 
official odoo, master)
- on multiple servers (your station, your internal git server, github, 
maybe your integration server or your production server)
So if you mix this all you get a big headache and a very specific workflow.

I've intended to write a comprehensive blog post on the topic for quite 
some time, I'll try to write it down once and for all.
Here's as attachment a diagram of what our own git workflow looks like.
Of course, we've scripted a lot of it to make it bearable.

_______________________________________________
Mailing-List: https://www.odoo.com/groups/community-59
Post to: mailto:community@mail.odoo.com
Unsubscribe: https://www.odoo.com/groups?unsubscribe