In SVN, "merging" is a bad, scary, no good word. In Git/Mercurial it's an everyday operation that happens so seamlessly 90% of the time that you don't even notice. The other 10% of the time, you have great tools (i.e. 3-way merge tools) that make it easy to reconcile conflicting changes.
Agreed. Amazing how much the right tool can change habits - for the extremely better. It has barely occurred to me that people might struggle with merges (at least, small feature merges) anymore.
Switch to git at a minimum, if possible.
On the Trello Android team we have a similar workflow to the web client and server developers. We merge in to a shared development branch when we have a complete feature or bugfix. With git's --no-ff this allows us to see when a new feature was implemented, and when bugs pop up we have a clear list of intersections where they could have been introduced. Our workflow is roughly based on an excellent post by Vincent Driessen, http://nvie.com/posts/a-successful-git-branching-model/.
I'd love to hear more about the Android team's CI tools. What do you build with? What do you test with?
If you can build some kind of SaaS Android CI system, you'd probably make heaps of cash. Android CI is just enough of a pain to do yourself that people would pay for a one click type solution.
We use gradle for building. The actual app is split into two, trello-app and trello-lib. Anything that can be done w/o Android like SQLite caching, API calls, etc., is done in trello-lib which is a plain Java library. It makes the dev cycle much faster since you can write a unit test and run it in a second.
We don't have CI setup yet. For the server we use something custom but will most likely be moving to Buildbot and with that we'll also setup Android CI.
With Subversion, you have a working copy with changes and then you do "svn update", and Subversion merges the upstream changes into your working copy. (But you don't normally call this merge.)
With Git, you have a working _repository_ with changes and then you do "git pull", and Git merges the upstream changes into your repository.
From the user's perspective, it looks about the same. But the Git merges are safer than the Subversion updates, because if the Subversion update messes up your working copy, you're stuck. But with Git, you always have (1) the commits you made locally, (2) the commits you just pulled from upstream, (3) the merge that was done by "git pull". And (1) and (2) can't get messed up, only (3) can get messed up. But you still have both your version (1) and their version (2) to go back to, so you have lots of chances to fix it.
Think of Git branches and the corresponding merges to be like Subversion updates with backups of the previous local working copy.
That's how we work on Brackets[1], and I think a lot of projects work that way. It depends what kind of version control system you use. It's pretty easy to do this with the "GitHub flow".
Yes, more or less a new branch for each fix. But with git and Kiln, it's really not a drag at all; the merges are generally really easy and mostly performed by our release manager when the card makes it to 'Ready to Merge'.
Do I understand correctly that your stable 'master' branch is always ready for release? Basically it means that changes (fixes) should be relatively small, otherwise they are released via channels, correct?
Everyone runs dev environments locally and tests. A dev environment is really easy to set up with mongo and node. Occasionally, we’ll put stuff on a staging environment if we want to test a database or infrastructure change. Big, experimental client changes go to the alpha channel on production.
So when you have 2 features/bug fixes in the same area, built in 2 different branches and deployed to isolated dev/test environments... the first time you might find out that they dont work well with each other is in Staging? Why wait for that when you could deploy to a common environment and catch issues sooner?
Btw... I am trying to get some teams in my company to get out of branching. So trying to understand your view (which is exactly what these teams are doing), hence these questions...
That rarely happens in our experience. With our internal board, we know who is working on what and in what area of the code. Plus, all code is reviewed by someone working in the same area.
The alternative, having everyone work on the master branch, is a bigger drag, because it introduces all sorts of coordination problems like "is the master branch in a state to be deployed? are your changes done?".
You are right, that would be the opposite extreme. What we do is that we create a branch and push our code every few hours. After a preset time, the branch is merged with the level 2 branch for code review/testing/regression etc., and after that to the main branch and then released to live production.
My experience has been that maximizing merges works best. If you're constantly merging, hardly any of your merges have any friction. The longer you're separate from the master branch, the more likely you are to get painful merges with conflicts and subtle bugs.
I recently switched to this approach and it works very well. No more "I want to push out this quick fix, but I have to wrap up this other thing first so I don't break the build".
With github it is especially nice. I push to a remote branch, which I can see when I go to the project page. When I click merge it shows whether or not the TravisCI build passed. If it looks good, then I click to auto-merge and it's all set. It is possible to even automate away that part as well and have the whole thing merge and deploy on push if the build passes, but I am not quite ready to take the plunge yet with that (too easy to botch a production release IMHO).
Yep. My team follows a similar workflow with Github - every feature, bugfix, etc is developed on a branch off of master, then merged back into master via pull request when it is ready for deploying.
It's a nice workflow, changes are very visible to the entire team and well summarized (by the commit history and any comments/discussion on the pull request itself). Making a new branch is a one-line operation (two if you count hooking it up to the remote), so no, I've never personally felt that was a drag. Sometimes it feels a bit silly to create a branch for a one or two line fix, but the visibility to the team is worth it.
I agree. I would pick 1 dirty branch with continuous builds and tests any time over several branches. I have worked with several branches too and it is always messy, lots of confusion and too many overheads (including the Release Manager guy).
I love trello... but I don't like the branching model... :)
That's how my team at work does things as well. It actually speeds things along much more quickly than doing a bunch of fixes in one branch, because if one of your fixes is held up by QA, all the others can still be merged independently.
Commit to 1 dirty branch; assume it is broken and let tests prove otherwise. When tests pass, you know it is a working branch, tag and release. I skipped a few steps for simplicity.
Here, merges are an exception, not the rule.
This workflow won't work without automated tests... is lack of automated testing the reason to have individual branches for features and bug fixes?
What we do is that we create a branch and push our code every few hours. After a preset time, the branch is merged with the level 2 branch for code review/testing/regression etc., and after that to the main branch and then released to live production.
This saves us some merging.