Mes: junio 2016

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

Delivery Pipeline con Jenkins 2

Si bien vengo trabajando con Jenkins2 desde que se publicó el release candidate, no había echado mano a la nueva funcionalidad nativa de pipelines. Sinceramente la miré por arriba apenas instalé Jenkins2, no me convenció y decidí seguir con la combinación de plugins que venia usando con Jenkins 1.6.

El lunes pasado me actualicé a Jenkins 2.8 y decidí investigar más en profundidad la funcionalidad de pipelines nativos.  Finalmente esta mañana logré completar una primera versión de mi pipeline utilizando el nuevo soporte nativo. Al hacerlo descubrí un montón de cosas interesantes que pueden llegar a disminuir considerablemente el costo de control de configuración de Jenkins (principalmente las cuestiones versionado, actualización y backups de jobs)

jenkins2-pipeline

 

XPConf 2016: algunas cosas para importar en Latam

Quiero compartir algunas actividades que viví en la conferencia y que podría resultar interesante tenerlas presentes para la conferencia latinoamericana Agiles.

Cena previa: la noche previa al inicio de la conferencia los organizadores realizaron reservas en diversos restaurantes cercanos al centro de conferencias para que los asistentes fueran a cenar en grupo con la intención de conocer a otros participantes. Cada uno debía pagar su cena, pero el hecho de que la organización hubiera hecho las reservas posibilitó que los lugares estuvieran preparados para atender mesas de 10 comensales.

Catering continuo: durante los 3 días que duró la conferencia hubo catering continuo, o sea, uno podia salir en medio de una sesión y ponerse a comer, no hacía falta esperar al break. Había breaks de 30 minutos a horarios predeterminados, pero el catering no estaba limitado a esos breaks, sino que estaba todo el día. Al mismo tiempo el catering estaba organizado en 4 espacios:

  • 1 espacio donde se servia café, té, agua y dulces
  • 3 espacios donde se servia comida salada que incluía: hamburguesas de distinto tipo, papas fritas, tartas, pizza, arroz, woks y pastas entre otros

Actividades «before office»: todas las mañanas antes de desayuno (7 AM) había sesiones de yoga, running y lean coffee.

Actividades «after office»: todos los días luego de la conferencia había actividades de networking: una degustación de whisky, juegos con premios de los sponsors, fiesta en el castillo, etc.

Open Space en paralelo: el market place del open space junto con la primera tanda de sesiones se hizo en el «after office» del primer día. Luego, el resto de las sesiones del open space tuvo lugar durante los días 2 y 3 a la par de las sesiones predefinidas del programa.

Si bien algunas de estas actividades puede que ya no sean factibles para la edición de Agiles este año, hay otras que me parece que perfectamente podrían realizarse.

xp_party

XPConf 2016: Day 3 summary

The day started with a keynote by Professor Lionel Briand who talked about «Documented requirements are not useless after all». He presented really interesting stuff based on concrete study cases. I liked it.

After the keynote I joined the session «Working effectively with legacy Test» by Nat Pryce and Duncan McGregor. The session started with a short introduction by Nat and then we started reviewing test code shared by the participants. While sharing the code we analysed and proposed different possible refactors. I like the dynamics of the session.

Next I jumped to the session «Bourne Again, Bootstrap a testing framework in BASH» where Rob Westgeest coded a «xunit-like» tool in BASH to test BASH scripts. It was simple great! I loved the session and it gave me lot of ideas.

In the afternoon I followed Woody Zuill to his session «No Estimates», I was already familiar with the topic but I wanted to see how Woody presented it. I really liked his approach and I enjoyed the session.

The last session of the day (and the conference) was a Keynote by Steve Freeman and Nat Pryce.

The closing of the conference was in charge of Seb Rose who was the host of the conference.

In the next post I will share some highlights of the conference beyond the «formal stuff».