Deployment Strategy/Guidelines For Gator Gems

[Dominic Graefen]

We need to address this issue as we are locking out people from development versions because of incorrect gem dependencies.

For example that a released gem of gator-as-robotlegs is linking against a develop version of gator and/or gator as3 which is not on RubyGems yet and has to be built and installed manually from source.

Right now we are working with this branching model: http://nvie.com/posts/a-successful-git-branching-model/

Which is good, and becomes really easy to apply when using git-flow (http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/).

But I started wondering if this is the correct approach for the gator gems after reading this post by github about their flow: http://scottchacon.com/2011/08/31/github-flow.html

We certainly cannot push "release" gems out as we develop, as this will probably lead to even more gem-dependency issues as we are having now.

But we could use the github-flow model on our develop branches, and instantly deploy "pre-release" gems (like "0.1.0.pre") from there.

This would allow us to quickly push pre-releases to ruby gems which are in sync, and will allow other developers to try them out and test them (for us).

Once we have reached a satisfactory state in our develop-branches, we can merge them into the master-branches and make a proper release from there.

To work with this model, we need to stop making changes on the develop branches and fork off into another branch for every feature, even if it is just a line of code that has changed. 

This way we can also use the pull-requests on github, to get feedback for upcoming merges of features into the develop branch which is also described in the github-flow blogpost. If you're confident you could just use git-flow to merge right away.

Additionally we can automatically setup builds on jenkins for every feature branch that has started, to have automated tests for them too.

Does this sound like a good combination of both work-flows or am I missing something?

-- 
Dominic Graefen

Freelance: Interactive Developer / Creative Technologist

devboy.org

[Simon Bailey]

I think this makes perfect sense and am up for giving this a go. I have just pushed a pre release gem so from now on all my changes will be in a feature branch, in fact I have to work on the modules generator so that will be the next feature branch for me.

--
Cheers,

Simon

[ http://newtriks.com ]

[devboy]

I am just working on gator for a bit. 

Once I cleaned up the code a little we can finally give this a try and put a new release on rubygems.

Once we get there we can think about writing some helpers for this with gator a la git-flow. :)

[Dominic Graefen]

I've added some rake tasks for jeweler to make prerelease's from a develop branch.

Once we can rip them loose from jeweler we can make a separate gem of it for gator ;)

Here are the tasks: https://github.com/devboy/buildr_as3/tree/develop/rake

-- 
Dominic Graefen

Freelance: Interactive Developer / Creative Technologist

devboy.org