Team City organizational setup alternatives

The way we decided to manage the continuous integration process is to have one build server per project, that is an exclusive virtual machine with a Team City install running on it. These strategy gives each team full control over the server without having to worry about other projects.

Other alternative, that I think is more frequently used, is to have only one build server for the whole organization and several build agents. When using this strategy the build server concentrate the all build configurations, checkouts the code and delegate to an agent the execution of the build steps. If you have two projects with incompatible software requirements (i.e. one project running on Windows and other on Linux), then you could setup one Windows agent and Linux agent.

Last week I setup an environment following this second alternative. I took 2 machines, in the first one I installed a full TeamCity environment: server and agent, and in the second one I installed just an agent. It was very straight forward. One additional benefit of this setup is that it allows run builds in parallel.

Retrospectiva del tutorial de integración contínua

Hoy dí el tutorial de integración contínua que anuncié hace un par de dias.

Como de costumbre comencé con una dinámica para romper el hielo y conocer el perfil de los asistentes. Resulto que todos estaban familiarizados con la práctica de integración contínua pero no todos las utilizaban. De la gran mayoría de la sí la utilizaba una una interesante porción no había realizado el setup del del ambiente de integración, sino que utilizaban un ambiente que alguién más en su organización había configurado.

Luego de la apertura, la sesión transitó guiada por esta presentación que armé para la ocasión. Sinceramente la presentación no fué tan interactiva como me hubiera gustado, pero que estoy contento con el resultado: pudé contar todo lo que habia planeado (e incluso algunas cosillas más), hubo espacio que los asistentes hicieran sus aportes y también para contestar consultas. Nadie se animó a trabajar a la par mia e ir configurando su propio ambiente, pero creo que en parte fue porque mi forma de encarar la sesión no fue lo suficientemente motivadora para ello. Definitivamente este es un punto a mejorar.Adicionalmente a lo expuesto en el material de la presentación, hablamos sobre algunas cuestiones conceptuales y también sobre algunas herramientas adicionales: Sonar, Janky and CloudBees.

Finalmente para cerrar pedí feedback con la técnica de las carita:

  • 🙂  18
  • 😐  0
  • 😦  0

(hay que considerar que unas 4 personas de fueron antes de que terminara la actividad)

Evento: Tutorial de Integración Contínua

El próximo miercoles a las  18.30 hs. voy a dar un tutorial de integración contínua en el contexto de los encuentros mensuales del grupo Agiles @ Buenos Aires.
La entrada es libre y gratuita, pero requiere registración previa. Los interesados pueden registrarse via Meetp up
A grandes rasgos la idea del tutorial es repasar los fundamentos que sustentan esta práctica y analizar distintas alternativas técnológicas para su implementación en los distintos lenguajes. Al mismo tiempo pondremos manos a la obra automatizando el build de algunos proyectos y resolviendo los problemas más comunes que suelen aparecer. Aquellos participantes que lo deseen pueden traer sus propias máquinas para trabajar y automatizar sus propios proyectos.

Build Servers Initiative

A couple of weeks ago I started helping some teams to set up their continuous integration servers. There are several tools and strategies you can use to accomplish this task. In our case, we decided to use MSBuild as the automation tool and TeamCity as the continuous integration server. Team City provides several features to automate the build process, but we preferred to minimize the dependencies with Team City for 2 main reasons:
  • We want to be able to run the automated build process in the devs machines.
  • We want to be able to use another build server.
For us, the standard build process includes:
  • Running source analysis (StyleCop)
  • Running code analysis (FxCop)
  • Compiling (CS compiler)
  • Running tests (MSTest)
  • Running coverage (VS build-it coverage feature)
MSBuild only provides built-in support to compile, so for the rest of these tasks we had to do some research. A couple of weeks ago Gabi Iglesias posted about some of the spikes we did.
After research and spiking, this is the approach we finally took:
  • To run StyleCop and FxCop we are using MSBuild Extension Pack, an open source project published at CodePlex
  • To run MSTest and coverage we are using home made MSBuild tasks developed by our Engineering Excellence team (these tasks were developed back in 2008, so for our new initiative we had to update them)
In upcoming posts we will provide more details on this topic.