Feature branches?

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Feature branches?

jewzaam
Administrator
Had a discussion with some folks at work today (Kevin and Michael who will hopefully join this conversation) about using feature branches.  I think that we need to talk about how we'll do this moving forward.  Once we're past RC1 (or maybe as late as GA) changes to lightblue should be self contained.  If not, we'll just make some exceptions.  Some notes from that discussion:

* have a single release branch: master
* all changes go through feature branches
* all changes to lightblue tracked as issues
* a feature is a collection of issues
* a feature could span multiple repos
* changes to master branch should be restricted to merges from feature branches only (enforce with hook?)
* merges of features results in one surviving feature
* pull requests could fulfill this need but from my experience github supports a single pull request on a repo from a user at a time (aka couldn't have one person working on two features concurrently)

How do we:
* collect issues together into a feature? (especially fun across repos)
* enforce adoption of this pattern?

I noticed today that waffle.io (which we use: https://waffle.io/lightblue-platform/lightblue) has integration with Rally Software. Rally gives profiles, which contain features.  And features are what we really need, collections of user stories (issues).  Maybe something down this path could be leveraged?  Worth investigating, I haven't looked at all.  One issue with Rally is we'd have to use a non-corporate account (since Red Hat IT uses Rally internally) and I don't know what we would get from Rally and not sure what the waffle.io integration would pull over.
Reply | Threaded
Open this post in threaded view
|

Re: Feature branches?

lcestari
I think pull requests (PR) can fulfill those things (a repository can have more than a single PR from an user, I saw some cases in wildfly as an example https://github.com/wildfly/wildfly/pulls )

I liked the work flow. I would just add that we could maybe simplify the processing just accepting PR to the master, if the dev create a single branch or many in his remote copy, no problem. Only very big changes would be a remote branch.

I would also suggest to use tag (and/or branches) on git for the releases. So we could know the git state on each important moment.

We could also create a release notes, just to summarize the changes/fixed issues/etc.

Answering those two question about feature and adoption. I don't know any other tool which is like waffle.io that could help with that. I would suggest to we take a look on atlassian jira, a issue tracker available for free for open source project (and many projects use it). On JIra there is tons of features, one of them you can put a dependency between issues, for example. About how we can make it very wide spread, I think if we stop using other channels (moving all to this tool), asnwering questions here (in nabble) and put a lot of references about it (on gitbook, wiki, readme, some commits or release), that would be probably enough.

Regards,
Luan
Reply | Threaded
Open this post in threaded view
|

Re: Feature branches?

lcestari
Just to mention, I also thought that master branch could be a type of dev branch as the PR are merged by default into master. If it pass all tests we could create a tag/branch with a new version (or after some user tests or a period).

Or, maybe we could have a branch named 'dev' which we could merge the PR there before the master (and also the features could go first into 'dev' branch than to the 'master' after the release) (more info https://stackoverflow.com/questions/9135913/merge-pull-request-to-a-different-branch-than-default-in-github )
Reply | Threaded
Open this post in threaded view
|

Re: Feature branches?

jewzaam
Administrator

I think releases can be handled by the maven release Plugin. From what I've heard it will manage creating a new version, tagging the commit, and creating a new commit with a snapshot version automatically.

On Aug 12, 2014 8:17 AM, "lcestari [via lightblue-dev]" <[hidden email]> wrote:
Just to mention, I also thought that master branch could be a type of dev branch as the PR are merged by default into master. If it pass all tests we could create a tag/branch with a new version (or after some user tests or a period).

Or, maybe we could have a branch named 'dev' which we could merge the PR there before the master (and also the features could go first into 'dev' branch than to the 'master' after the release) (more info https://stackoverflow.com/questions/9135913/merge-pull-request-to-a-different-branch-than-default-in-github )


If you reply to this email, your message will be added to the discussion below:
http://lightblue-dev.1011138.n3.nabble.com/Feature-branches-tp18p23.html
To start a new topic under lightblue-dev, email [hidden email]
To unsubscribe from lightblue-dev, click here.
NAML
Reply | Threaded
Open this post in threaded view
|

Re: Feature branches?

khowell

I have a suggestion for the feature branch merging: always merge with --no-ff, so that the merge is always traceable.

From the documentation for the release plugin (http://maven.apache.org/maven-release/maven-release-plugin/examples/prepare-release.html), the plugin does the following:
  • Check that there are no uncommitted changes in the sources
  • Check that there are no SNAPSHOT dependencies
  • Change the version in the POMs from x-SNAPSHOT to a new version (you will be prompted for the versions to use)
  • Transform the SCM information in the POM to include the final destination of the tag
  • Run the project tests against the modified POMs to confirm everything is in working order
  • Commit the modified POMs
  • Tag the code in the SCM with a version name (this will be prompted for)
  • Bump the version in the POMs to a new value y-SNAPSHOT (these values will also be prompted for)
  • Commit the modified POMs

The prompting can be avoided if you provide the desired versions (via additional args: see http://maven.apache.org/maven-release/maven-release-plugin/examples/non-interactive-release.html)

On 08/12/2014 08:56 AM, jewzaam [via lightblue-dev] wrote:

I think releases can be handled by the maven release Plugin. From what I've heard it will manage creating a new version, tagging the commit, and creating a new commit with a snapshot version automatically.

On Aug 12, 2014 8:17 AM, "lcestari [via lightblue-dev]" <[hidden email]> wrote:
Just to mention, I also thought that master branch could be a type of dev branch as the PR are merged by default into master. If it pass all tests we could create a tag/branch with a new version (or after some user tests or a period).

Or, maybe we could have a branch named 'dev' which we could merge the PR there before the master (and also the features could go first into 'dev' branch than to the 'master' after the release) (more info https://stackoverflow.com/questions/9135913/merge-pull-request-to-a-different-branch-than-default-in-github )


If you reply to this email, your message will be added to the discussion below:
http://lightblue-dev.1011138.n3.nabble.com/Feature-branches-tp18p23.html
To start a new topic under lightblue-dev, email [hidden email]
To unsubscribe from lightblue-dev, click here.
NAML



If you reply to this email, your message will be added to the discussion below:
http://lightblue-dev.1011138.n3.nabble.com/Feature-branches-tp18p25.html
To start a new topic under lightblue-dev, email [hidden email]
To unsubscribe from lightblue-dev, click here.
NAML

Reply | Threaded
Open this post in threaded view
|

Re: Feature branches?

jewzaam
Administrator
In reply to this post by lcestari
A write up on doing multiple pull requests.

http://stackoverflow.com/questions/8450036/how-to-open-multiple-pull-requests-on-github

Simple answer: use different branch for each request.
Reply | Threaded
Open this post in threaded view
|

Re: Feature branches?

jewzaam
Administrator
And how to close issues with a pull request:

https://github.com/blog/1506-closing-issues-via-pull-requests

Summary: include the "fixes #X" text in a commit message

When the pull request is merged, the issue is closed.

We do reviews of all issues, but I think this is probably ok since we'll be doing a review of the pull request.  No sense doing additional review of the issue.

Thoughts?
Reply | Threaded
Open this post in threaded view
|

Re: Feature branches?

jewzaam
Administrator
Tried this out today with two small issues that needed fixed for RC1.  Did two different branches in a fork, simply named after the issue #.  Some notes:
* travis-ci built the pull requests and the status of the build is shown on the web UI for the PR
* there was a merge conflict after the first PR was accepted, web UI immediately showed it couldn't be merged
* upon fixing merge conflict in my fork's feature branch, PR was updated to say it could merge AND travis-ci build was kicked off

Overall I like this pattern.  It's easy and gets us to separate commits cleanly.  Some quirks:
* the waffle.io tag "ready for review" was not removed on merging the PR
* the waffle.io tag "ready" was not removed from the issue on merging the PR

Though the tags were not removed, the PR and issue were closed.  I will post a request for update to waffle.io to hopefully fix this.
Reply | Threaded
Open this post in threaded view
|

Re: Feature branches?

jewzaam
Administrator
One issue with this is in cases where the change needs to be deployed to be tested.  For example, puppet changes.  For now just doing those straight to master..
Reply | Threaded
Open this post in threaded view
|

Re: Feature branches?

lcestari
I also like that approach, but for puppet and other exceptional cases we could move things directly to master (with much more attention to not break it) (if it breaks somehow, we could make a mechanism to rollback before the commits been  pushed and move that change to an specific branch for analysis, just an idea)