Padrões para integração contínua e DVCS

12

Atualmente, usamos o Subversion e o TeamCity, vamos usar o Mercurial (especificamente o Kiln como usuários do FogBugz).

Obviamente, isso resultará em mudanças - espero que melhorias - em nossos padrões de desenvolvimento (todos nós!), Mas o problema com o qual estou lidando é como estruturar as coisas para que ainda usufruamos dos benefícios da integração contínua / nosso servidor de IC ( que existem e permanecerão benefícios é um dado, cuja discussão está fora do escopo desta questão).

Com o SVN, estamos comprometidos com um número limitado de repositórios centrais - efetivamente um por projeto (mais ou menos uma solução do Visual Studio), para facilitar a criação de uma compilação e obter a garantia de que todos os arquivos foram confirmados e que não existem dependências perdidas etc, etc. Mas, se quisermos tirar o máximo proveito do mercurial, queremos ter mais instâncias de repositório - onde eu esperaria que as mudanças geralmente fluíssem em direção a um repositório definitivo "ao vivo". O problema com o qual estou lutando é que o repositório ao vivo parece estar "atrasado" demais para acionar minha criação de IC OTOH Uma criação de IC por projeto por desenvolvedor provavelmente é excessiva (e causa outros problemas).

I'm fishing a bit but that's because one of the things that a central subversion repo gives one (me, with our setup!) is a lot of clarity about what to build when.

n.b. I'm not asking about the mechanics of using mercurial with continuous integration - I have that working a treat for a personal project, its patterns and structures and working practice/workflow that I'm trying to get my head round.

continuous-integration dvcs

— Murph
fonte

Why do you think it is too late to trigger builds from the central/"live" repo?

— c_maker

If you haven't been there already, I suggest you head on over to the Kiln stack exchange site (kiln.stackexchange.com). They have quite a bit of content about how to set this up (here's one: kiln.stackexchange.com/questions/29/…. Personally, we use a branch per feature, and point the build server at our "master" branch.)

— Chris Phillips

@Chris - I have, there isn't really, not addressing the CI issue...

— Murph

2

First, having multiple builds per project in TeamCity is really the way to go. The nature of the platform makes it really easy -- the copy button is there for a reason.

In any case, when we were on SVN, we typically ran 2 builds for each project -- one pointed at the main development line (in our case the trunk) and one pointed at our release branch. We carried this build setup over to HG while following a branching model similar to this one . Only real challenge has been finding a new funk schwea about build numbers now that we could no longer use current SVN revision number.

We try and encourage folks to push relatively often, especially when there is lots of work going on at once and we wanted faster feedback cycles. Just because it is a DCVS doesn't mean you have to only push once a day or something.

— Wyatt Barnett
fonte

Wyatt, to my mind push should occur when you have a completed unit of work (ish) - one of the benefits of DVCS is that we can commit, locally, code that is broken. I really really dislike the notion of doing anything on a schedule because its the end of the day. There is a separate issue of "backup", that - to me - is about setting up a rule to push sideways - on commit - to another clone that exists just to be a backup.

— Murph

2

Trick there is what is the definition of unit of work? Is it "this feature is complete" or is it "this brick is successfully laid". We tend towards the latter, especially with that branching model where there is a clearly deliniated development branch. Breaking stuff is best left to feature branches. Long-running ones of those can get CI builds too if possible. Especially if there are multiple cooks in the kitchen.

— Wyatt Barnett

I agree with your definition of "unit of work" which is why I'm struggling a bit with my overall model (which already has multiple builds per project variously to accommodate both "CI" builds and "deployment" builds). You're right, the answer is to wire up lots of builds so in the end my real issue is going to be getting the cheque signed! The branching model referenced looks about right - too. Still considering the overall pattern (and allow that that will get further adjusted to allow for specifics of kilnhg)

— Murph

2

We've been using Kiln for about a year now and have tried several different things. Where we've ended up is to used named branches (as opposed to branch clones) with the following branching strategy:

default tracks "completed" development
feature branches track work that's currently in progress
release branches track points where we released from default

So, work starts by creating a feature branch from the current tip of default. When the feature branch is done*, the branch is closed and merged back into default.

At some point, we decide that we're ready to release, so we create a new release branch from the current tip in default. This allows us to make changes to the code that's currently in production by committing to the release branch while still allowing active development on the feature branches and default.

As for continuous integration, we do two things:

An "always on" integration that monitors the status of default
New integrations for each release branch

The default branch job lets us know that our main source tree is always stable -- the release branch jobs let us know that those branches are stable and provide us with the build output we need to push a release into production.

_{*Our definition of "done" is that the feature is up-to-date with merges from default and has been approved in code review.}

— Chris Phillips
fonte

1

If you move to a DVCS, like Hg, you're not only getting the "distributed part", you're also getting the full power of good branching and merging.

Considering that now you'll have a good issue tracker and a good SCM... why not creating a branch for each task?

The "branch per task" pattern is not new (check Berczuk's book) but it is definitely something to try.

I explained it in detail here, and the pros and cons of CI vs "controlled" here.

— psantosl
fonte

I would say "better" rather than "good" since I've happily, enthusiastically and successfully done both feature and maintenance branching and merging with subversion (-:

— Murph