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.
fonte
Respostas:
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.
fonte
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:
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:
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.
fonte
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.
fonte