Fixing the Ubuntu Xenial Vagrant Box

The official vagrant box of Ubuntu Xenial 64 was initially with a issue: it didn’t have a vagrant user (according to Vagrant recommendations all boxes should have a user with name vagrant and password vagrant).

A recent release fixed the problem in a partial way: the user vagrant was added, but it is not possible to use it with password authentication (a feature that I usually need in my workshops).

So to fix this issue I created a new vagrant box based on the official Xenial box. I added the following lines in the shell provisioner:

echo "vagrant:vagrant" | sudo chpasswd
sed -i -e 's/PasswordAuthentication no/PasswordAuthentication yes/' /etc/ssh/sshd_config

The first line set the password vagrant for the user vagrant. The second line enables PasswordAuthentication.

Configuration Management in my .NET project

On these days I am working on big system that is built on several components: a couple of websites, some backend services and several shared libraries. At this moment all these components are stored in the same Subversion repository. As you can image, this is a huge repository. At the same time, the system is already running in production mode and some components are being updated/replaced. Because of this situation and in order to simplify configuration management I being working on designing a new configuration management strategy. The solution I have in mind includes 3 key tools:

  • Git: to store source code, in particular I like GitHub service
  • NuGet: a package manager for .NET components (for those not familiar with .NET, it is like a Maven in Java o npm in Node). We know we will need a private Gallery for some components, but we still don’t decide if  we are going to host our own instance or if we will use a cloud service.
  • Jenkins: to provide continuous integration and deployment automation

Now I will try to explain how these components fit together.

Each shared library has its own Git repository. In case a library depends on third party component, it should declare the dependency package.xml for Nuget to download the dependency at build time. At the same time, stable versions of share libraries are published in NuGet Gallery (possible a private one).

Each application has its own Git repository. In case an application depends on third party component, it should declare the dependency in package.xml for Nuget to download the dependency at build time. In case this application depends on a  private share library there two options:

  • If the shared library will be used as it is, then it is managed with NuGet
  • If the shared library needs to be modified, then the shared library repository is added as a submodule of the application repository. This way you will be able to add the shared library project to your Visual Studio solution and will be able to modify it.

At the same time, Jenkins will monitor all repositories and trigger a CI job to compile and run automated tests on each change. For each application there will be additional Jenkins Jobs to perform deployments to the different environments. For each shared library, there will be a Jenkins job to publish the library to the NuGet repository.

scm

Notas para instalar Jenkins en Ubuntu

Una de las cosas más me gusta de las distribuciones basadas en Debian es la facilidad para instalar software utilizando apt-get.

Jenkins puede instalarse utilizando apt-get, pero antes de ejecutar apt-get install jenkins,  uno debería actualizar la configuración de su repositorio de paquetes para así asegurarse de instalar la última versión. Esta página describe el proceso completo de instalación.

Enjoy it!

Travis y Jenkins al mismo tiempo

S bien ambas herramientas son build servers y en general uno utilizará alguno de los dos, en ciertos casos puede resultar muy útil utilizar ambos al mismo tiempo. Esto es hago que he hecho en mis últimos 3 proyectos.

Si bien, en varios sentidos Jenkins puede resultar mucho más “potente/flexible” que Travis, resulta que este último tiene una funcionalidad “matadora”: buildea todos lo branches existentes en el repositorio, sin requerir ninguna configuración adicional. Esto resulta especialmente útil cuando uno utiliza feature branches. Por su parte, Jenkins no tiene soporte actualmente para buildear varios branches en un mismo job. Claro que es posible jugar un poco con algunos plugins y lograr un workaround para lograrlo, pero no es algo out-of-the-box ni tampoco trivial.

Entonces, si para integración continua utilizo Travis, ¿para qué utilizo Jenkins? Simple, para automatizar mi proceso de despliegue y ejecutar algunas otras tareas que no puedo ejecutar con Travis como ser: enviar notificaciones via chat/sms, generar reportes, ejecutar tests de larga duración, etc.

Tools for Git

There is a simple but extremely useful tool to work with Git. It is not a graphic interface nor an IDE plugin. It is just an extension to the shell. It is called oh-my-zsh and, among other things, it provides a feature that shows the current git branch you are working on, when you are browsing a git directory.

To install this tool, you just have to follow these simple steps:

  1. The tool is an extension to zsh shell, so you have to start by installing zsh: apt-get install zsh
  2. Then you could want to set zsh as you default shell: chsh -s /bin/zsh <user_name>
  3. Install oh-my-zsh: curl -L https://github.com/robbyrussell/oh-my-zsh/raw/master/tools/install.sh | sh
  4. Close the terminal and restart you OS session

That is all, you are done!.

git-tools

Tutorial de aplicaciones Padrino: parte 1

En esta primera parte veremos la configuración inicial de nuestra aplicación y algunas de las herramientas que utilizaremos a lo largo del tutorial. La idea trabajar con un entorno como el descripto en el post inicial de esta serie, partiendo de esta solución y siguiendo los videos explicativos.

  • Creación del repo git y primer commit, ver.
  • Creación de la aplicación base con Padrino, ver.
  • Configuración de Travis (build server), ver.
  • Ajustes de configuración en la aplicación base que genera Padrino, ver.
  • Generación de un objeto de negocio (model) con Padrino, ver.
Continuará…

Customize Jenkins header

I am talking about this:

jenkins

  1. Create a logo image of size 130×60 px
  2. Upload the image to web accessible location
  3. Copy this style sheet
  4. Adjust line 6 to set the header background color
  5. Adjust line 14 to point to your logo image
  6. Upload the style sheet to a web accesible location
  7. Enter Jenkins and install the Simple Theme Plugin.
  8. Go to Manage Jenkins > Configure System, look for the Theme section
  9. Set the URL of theme CSS to point to you style sheet
  10. After saving the changes you should see your new style applied

Implementado un pipeline de continuous delivery en .Net

La semana pasado estuve trabajando en el tema de referencia. Como suele ocurrir cuando se trabaja con tecnología Microsoft, el stack de herramientas a utilizar es bastante distinto del utilizado al trabajar con tecnologias no-Microsoft.

Como build server hicimos un primer intento de usar TFS, pues el proyecto ya lo venia utilizando como repositorio de código y herramienta de gestión. Pero luego de dos problemas, desistimos y decidimos apostar a lo seguro: Team City. ¡Ja!, seguro que más de uno pensó que iba a decir Jenkins. No, hace un año aproximadamente analicé ambas herramientas y llegué a la conclusión que para ambientes Microsoft era más apropiado utilizar Team City.

Como herramienta de build usamos MSBuild.

Para realizar los pasajes entre ambientes, dado que nuestra aplicación es web, optamos por la propuesta de Microsoft: MSDeploy.

Continuará…

Algunas prácticas para organizar el trabajo

Hoy quiero compartir algunas prácticas para organizar el trabajo que cobran mayor relevancia cuando uno trabaja de forma independiente.

Establece horarios

Puede que al sentirte más dueño de tus tiempos terminés trabajando en cualquier horario, lo cual luego te lleva a comer en cualquier horario, lo cual te lleva a dormir en cualquier horario, lo cual te lleva directamente a un mal estado de salud.

Estaceble tu horario de trabajo dentro del horario comercial o a lo sumo sólo un par de horas defasado. Al mismo tiempo no te acostumbres a contestar mails de los clientes fuera de tu horario y si lo haces, escribelos, pero no los envies, no es bueno que los clientes se acostumbren a que les respondas en cualquier horario.

Evita el cambio de contexto

Cada cambio de contexto, requiere cierta adecuación lo cual disminuye tu productividad al tiempo que “va limando tu cabeza”. Esto lo vivo todos los jueves y me afecta al extremo. Un jueves típico, comienzo el día programando C#, luego doy clases en FIUBA con Smalltalk y finalmente cierro el día dando clases en UNQ con Ruby, al llegar a casa tengo menos cerebro que una lechuga.

Si trabajas en consultoría y debes visitar a tus clientes, intenta aprovechar al máximo cada visita. Yo generalmente intento particionar mi dia en 2 slots: mañana y tarde. Cuando agendo una sesión de trabajo con un cliente busco, dentro de lo posible, que ocupe todo el slot.

Planifica con anticipación suficiente

El planificar tus actividades con anticipación te permitirá acomodarlas mejor en tu agenda y prepararte apropiadamente para llevarlas acabo. Personalmente intento programar todas mis actividades con al menos una semana de anticipación y siempre intento a más tardar el viernes al mediodia tener definida mi agenda de la semana siguiente.