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.


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 | sh
  4. Close the terminal and restart you OS session

That is all, you are done!.


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.