Setting up a .net build server without Visual Studio

Usually setting up a build server is a very straight forward task but not always. In case you want to build .Net applications it could be a non-trivial task because of the tight coupling of the different build tools with Visual Studio. A simplified way of dealing with this complexity is to install Visual Studio in the build server. I took that approach in the past and I didn’t want to go that way again. I don’t want Visual Studio in the build server.

In a previous post I described the approach I took to simplified the setup of the different build tools I want to integration in my build process. But that approach does not work if you don’t have Visual Studio, FxCop will not work and at the same time you will get lot of warning messages because of missing dependencies. So here is what I have to do:

  1. Get a machine with Windows Server 2012 R2
  2. Install .Net SDK 4.5.2
  3. Install Microsoft Build Tools 2015
  4. Install Windows 7 SDK and .Net 4 SDK (not the whole package but only Reference Assemblies)
  5. Install .Net 3 assemblies (it can be installed by using the Add feature option in windows, so you don’t need any additional download)

With all this stuff installed in your server, then you can use the approach I described previously and just use your build server to trigger MSBuild to take care of running all your build tasks.

SoCraTes arrives South America

SoCraTes arrives South America

Next Friday, July 1st, the Software Craftsmanship and Testing Conference will arrive to South America. It will be hosted at Universidad de Chile.

I have just bought my ticket so in the next couple of days I will start preparing a session proposal (the agenda is full open space). I have 2 possible topics in mind:

  • Bringing technical excellent to legacy projects: since I started my freelancer activity the majority of the projects I have been involved were legacy projects. In that contexts my main concern was always remove technical impediments in order to enable the continuous delivery of business value. So the idea of this session is to share some patterns and practices to face this challenges.
  • Continuous Delivery at Scale: setup a Jenkins server and configure a couple jobs to automate integration and deployment is an “easy task”, but the situation get complex when you have to manage hundred of projects and at the same time follow several organisational policies. This session is about patterns and recommendations to deal with this stuff.

I don’t have enough time to prepare both sessions, so I have to pick one. What would you prefer?

 

Integrating .Net Build tools: MSBuild, NuGet, FxCop, StyleCop and NUnit

These days it is very common to have a continuous build process that includes: compilation, code analysis and automated tests. The way of implementing this kind of process varies depending on the technology of the project.

I have worked with Ruby, Python, Java, JavaScript, Smalltalk and some other languages and in all cases you just need to install 3 tools:

  • the runtime/sdk (like ruby, jdk, cog)
  • a package manager (like bundle, maven, pip, metacello)
  • a build tool (like rake, maven, fabric)

Any other thing you may need (linter, testing framework, etc), you can get it using the package manager and make it run as part of your build script.

But in .Net the situation is more complex. First of all everything seems to be very tight to Visual Studio (the IDE). Because of this, many people just install the Visual Studio in the build server.

Additionally to this the .Net SDK does not provide a test framework. You can use NUnit (which you will have to install manually) or you can use MSTest but to use it you need to install Visual Studio.

FxCop (the linter) comes with Visual Studio but if you don’t want Visual Studio, then you have to install it manually.

So, in order to avoid several manual tasks when setting up a new dev box and also to minimize any possible difference between dev boxes and the build server box I did the following:

  • I downloaded all the tools I wanted to use in my build process and placed them into the same directory (c:\BuildTools).
  • I wrote a build script (using MSBuild and defining my own targets). This script “glues” the invocation to all of these tools: NuGet, FxCop, StyleCop and NUnit.
  • Finally I package all these stuff in a self-extracting .zip file so all the team members can easily replicate my setup.

In order to have the build process to run continuously I also installed this package in the Jenkins build server.

buildtools-v4buildtools-layout

Jenkins: Jobs as Code

Jenkins: Jobs as Code

Una de las funcionalidades destacadas en la nueva versión de Jenkins es la posibilidad de definir los pipelines utilizando un lenguaje de dominio específico. Esto resulta muy útil cuando uno tiene que manejar una cantidad importante de jobs y al mismo tiempo facilita el control de configuración ya que permite que la definición de los jobs sea tratada como código en lo referente al almacenamiento y versionado.

Esta posibilidad de manejar los jobs como código es algo que está ahora más presente en Jenkins 2, pero la realidad es que es una funcionalidad que ya estaba disponible para las versiones anteriores de Jenkins mediante el uso de plugins y algunas otras herramientas.

En particular yo venia utilizando el Jenkins Job Builder, una herramienta de la gente de Open Stack que permite definir jobs en un archivo .yml, definiendo también relaciones “de herencia” entre los jobs. El Job build es básicamente un script python que parsea los .yml y utiliza la api de Jenkins para crear los jobs correspondientes.

Otra herramienta que provee una experiencia similar es el Job DSL Plugin. Este plugin provee la posibilidad de definir Job utilizando un DSL Groovy para la definición de Jobs. La forma de uso es: poner los scripts de definición de jobs en un repo y luego crear un job en Jenkins (típicamente llamado Seed) que monitorea el repo de scripts y que cuando detecta cambios ejecuta los scripts los cuales generan los jobs que hayamos definido.

Otras herramientas similares pero que no he probado lo suficiente son: el Build Flow Plugin y el Workflow plugin.

El camino freelance, parte 5: dos prácticas de gestión

El camino freelance, parte 5: dos prácticas de gestión

Cuando uno es contratado para un trabajo es de esperar que uno realice su trabajo de forma correcta, o sea: si me contratan para programar entonces debería programar bien (además de asegurarme de estar programando lo que el cliente espera), pero más allá de eso creo que hay otra serie de cuestiones importantes particularmente cuando uno trabaja en un esquema time & materials. Entre todas esas cuestiones hay dos que aplico siempre porque me ayudan mucho en la ejecución de mis proyectos.

Visibilidad continua

Dado que el cliente estará pagando por el tiempo que nosotros dedicaremos al trabajo me parece una obligación dar visibilidad de las cosas que hacemos. Y cuando hablo de visibilidad no me refiero a un mail semanal con un resumen de lo que hice en las pasadas 40 horas. En algunos contextos eso puede estar bien, pero yo prefiero trabajar con una visibilidad más granular para así permitir a mi cliente accionar y corregir el plan de acción en caso de ser necesario. En ese sentido yo suelo reportar a nivel diario. Básicamente informo todos los días: que hice, en que estado está, y que voy a hacer a continuación.
Comparto aquí uno de mis mails de proyecto mostrando este tema de la visibilidad.

Hi guys,

Today I completed the OAuth integration (story#7533). Unless you have a different opinion I will move it live today 5 PM (EST).

Next Steps: I will continue with story#7536 that was reported today as urgent.

Regards,
NicoPaez

Acción por defecto

Si bien siempre es bueno tener el OK del cliente antes de avanzar con una tarea, no todos los clientes responden rápidamente lo cual puede ocasionar que uno quede bloqueado, cruzado de brazos por horas o incluso días.  Si me quedo cruzado de brazos si cobrar ese tiempo, pierdo plata, pero si lo cobro el que pierde plata es mi cliente, lo cual a largo plazo también también me perjudica a mi. Para evitar esto lo que suelo hacer es pedir validación y proponer una acción defecto en un determinado tiempo límite.

 Hola Ale,

Te cuento que ya tenemos todo el código y datos listos para correr las pruebas de stress (ticket#362) y estaríamos en condiciones de comenzar con su ejecución mañana mismo.

Tal como hablamos la semana pasada, para ejecutar estas pruebas necesitamos una cuenta en ABCDE. En teoría la cuenta iba a estar disponible el lunes, pero aún no lo está. Entonces si la cuenta no está para mañana lo que haremos de cara a evitar retrasos en el proyecto es correr las pruebas con mi propia cuenta y luego arreglamos entre nosotros el pago.

Saludos,
NicoPaez

Me parece importante destacar que estas prácticas pueden resultar útiles en muchísimos contextos distintos, pero creo que cobran mayor relevancia en el caso particular de contratos time&materials.

Fin de proyecto

Fin de proyecto

Luego de 3 intensos meses esta semana terminé mi segundo proyecto inmersivo del año.  Me sumé al equipo para dar una mano con cuestiones de arquitectura y operaciones, pero como de costumbre, al trabajar inmersivamente con el equipo uno siempre termina en medio en otras cuestiones. En estos tres meses además de completar diversas funcionalidades también hicimos lo siguiente:

  • Corrimos pruebas de performance y en base a ellas hicimos diversos ajustes en la aplicación.
  • Diseñamos e implementamos una infraestructura escalable basada en AWS
  • Implementamos un proceso de despliegue automatizado basado en CodeDeploy
  • Instrumentamos la aplicación para posibilitar su monitoreo con New Relic y CloudWatch
  • Pasamos de un esquema de trabajo basado en iteraciones de 2 semanas a un esquema de entrega continua liberando funcionalidad tan pronto como se completa

En verdad disfrute mucho ser parte del equipo y estoy muy conforme con el trabajo realizado.

 

El tercero de la trilogía: Ensayos ágiles

En el primer libro contamos experimentos, casos de aplicación, experiencias del uso de métodos ágiles en diversos contexto.

En el segundo libro fuimos más allá presentamos técnicas, generalizaciones surgidas a partir de las experiencias vividas.

Mi idea para el tercer libro es reunir ensayos: reflexiones, cuestionamientos, críticas, desafíos al estado del arte y a los estándares preestablecidos.

Veo en esta serie de libros una evolución similar a la propuesta por el modelo Shu-Ha-Ri, siento este tercer libro el correspondiente al nivel Ri.

No se cuantos me seguirán en la iniciativa, pero lo voy planteando con bastante antelación pues me parece que esta propuesta puede llegar a requerir bastante más tiempo de trabajo que las anteriores.

ensayos_agiles