

Are Git and Mercurial Anti-Agile? - taylorbuley
http://www.grahamlea.com/2013/11/git-mercurial-anti-agile-continuous-integration/

======
misnome
DCVS is good because you can have tracked local changes. Sometimes you are
doing a larger change to the software that takes a while and may require some
thought, without stacking up hundreds of minor changes sitting in the source
folder uncomitted that get applied simultaneously (a la CVS and SVN) and
merges happen into that working folder, with no reversability.

You could make the same argument all the way down to requiring that every
single line changed is committed at the instant of writing (otherwise they are
hiding their code!).

Without tools like Git and Mercurial, people are still doing exactly the same
behaviour, just it isn't being source controlled.

------
tunesmith
Something about this seems orthogonal to me. There's nothing about dvcs itself
that implies a lack of fluidity in a codebase, is there?

In a rough attempt to get down to first principles, CI means you need to be
able to deploy a codebase at anytime. Feature development means that codebase
needs to be ever-changing. Successful deployment means the codebase needs to
be at a level of guaranteed quality.

This means that the quality of a "change" needs to be guaranteed to some level
_before_ it is merged to the deployment branch.

So right there, that implies the need for "changes" to be developed and
quality-checked somewhere other than on the deployment branch.

I think that takes us pretty inexorably to the practice of branching the
codebase, developing there, quality-checking there, and also merging _from_
the deployment branch into the feature branch as the deployment branch
changes.

So what's left is qualifying what is meant by "change". Is it one feature? A
story? A functionality layer? That can be harder to decide on. Agile says it
should be a ui-focused story, but sometimes stories are epics (like a simple
form submission that somehow implies several SOA services be set up to make it
work). So I think that means we can still do functional dependency analysis
and shrink stories down to smaller functional steps, sometimes.

The key is to keep stories/features small enough so that they aren't in
progress for weeks at a time. When you're working on a feature and then are
faced with a _massive_ merge _from_ the deployment branch, that's where things
get messed up.

------
Arzh
" Dave Farley (co-author of ‘Continuous Delivery’) describes Continuous
Integration as the process of automatically creating a potential release
candidate after every commit. Are feature branches going to help you do that?
"

I think so, if you build a feature outside of the main branch, test it fully
and prepare it correctly, the commit to the main branch will be a potential
release candidate. You can't say that if you are integrating a potentially
broken feature into the main branch everyday.

I've never seen a git crew work in isolation before. If two teams or people
are working on two different modules that need to work together they are still
integrating between themselves on a regular basis. It's just that those
changes do not get pushed up to main until they are finished.

------
awkward
The issue is that the C in CI is a convenient fiction. Someone on your team is
always going to be changing the code, which means that they will have it, at
some point, in a state that fails validation. Requiring that they get it to a
point where it's fully passing is fine, but in many cases that just means a
longer time before checkins.

DVCSes, on the other hand, bring to the surface and keep in the record that
the code is always branched to some degree. It's not that it's incompatible,
it's that it's giving more granular information than the CI process can work
with or needs.

------
w_t_payne
I strongly agree with the fundamental point that the author is making.

However, there are nuances. A lot of this depends on the type of development
that you are doing.

For example, most of my day-to-day work is done in very small increments.
Minor bug-fixes, incremental classifier performance improvements, parameter
changes, and so on. Only rarely will I work on a feature that is so
significant in its' impact that the work-in-progress causes the branch to
spend several days in a broken / non-working state. I also work in fairly
small teams, so the rate of pushes to Gerrit is quite low: only around a dozen
pushes per day or so. This means that integration is pretty easy, and that our
CI server gives us value & helps with our quality gating. We can follow a
single-branch development path with little to no pain, and because both our
software and the division of labour in the team are fairly well organised,
conflicts very very seldom occur when merging (even when using suboptimal
tools to perform the merges).

This state of affairs probably does not hold for all developers, but it holds
for me, and for most of the people that I work with. As a result, we can
happily work without feature branches (most of the time), and lean on the CI
process to keep ourselves in sync & to measure the performance of our
classifiers & other algorithms.

Now, don't get me wrong, I think that Git is great. I am the nominated Git
expert in my team, and spend a lot of time helping other team members navigate
the nuances of using Git with Gerrit, but for most people it is yet another
tool to learn in an already over-complex development environment. Git gives us
the flexibility to do what we need to in the environment that we have; but it
is anything but effortless and transparent, which is what it really needs to
be.

Software development is about developing software. Making systems that work.
Not wrangling branches in Git.

My ideal tool would be the bastard son of Git and a real-time collaborative
editor. My unit tests should be able to report when my local working copy is
in a good state. Likewise, my unit tests should be able to report whether a
merge or rebase has succeeded or failed. Why can I not then fully automate the
process of integrating my work with that of my colleagues? Indeed, my work
should be integrated & shared whenever the following two conditions are met:
1) My unit tests pass on my local working copy, and 2) My unit tests pass on
the fully integrated copy. These are the same criteria that I would use when
doing the process manually ... so why do it manually? Why not automate it?
Triggered by every save, the resulting process would create the appearance of
an almost-real-time collaborative working environment, opening up the
possibility for new forms of close collaboration and team-working that are
simply not possible with current tools. A source file would be a shared
document that updates almost in real time. (If it is only comments that are
being edited, then there is no reason why the updating could not actually be
in real time). This means that you could discuss a change with a colleague,
IRC-style, in the comments of a source document, and make the change in the
source file _at the same time_ , keeping a record not only of the logic
change, but also of the reasoning that led to it. (OK, this might cause too
much noise, but with comment-folding, that might not matter too much).

Having said all of that, branches are still useful, as are commit messages, so
we would still want something like Git to keep a record of significant
changes, and to isolate incompatible works-in-progress in separate branches;
but there is no reason why we cannot separate out the "integration" use case
and the "collaboration" use case from the "version control" and "record
keeping" use cases.

------
voidr
I strongly disagree with this whole notion, I think in fact that the opposite
is true.

With Git you can make sure that you merge when your story is actually done,
with Subversion you need to worry about other's changes if you commit all the
time.

With feature branches you only have to worry about integration into the
mainline once, when your task is complete, which makes continuous integration
far easier than with the SVN model.

If we would need to call a VCS anti-agile, I think that would actually be SVN,
which makes continuos delivery a lot harder.

------
w_t_payne
Git and Mercurial make CI harder. CI is an important part of the discipline
needed to make Agile work. (CI is an important part of making anything work).
You can still do CI with Git and Mercurial. (If I can, anyone can). But you
need to fight the tools (a little bit). Fortunately, Git is super-flexible,
and you can make it do (almost) anything.

------
programminggeek
We use gitflow and it works well for us. We run tests before integrating. git
isn't anti-agile at all. I don't understand the article.

