El rol de build engineer

Una de las posiciones que más hemos intentado presionar donde trabajo para que se contratase es la de release/build engineer.

No cabe duda que hoy en día construir software es más complejo (no necesariamente más difícil) que hace años. La cantidad de diferentes sistemas que intervienen en el funcionamiento de una aplicación hace que crear una release sea mucho más complicado que hace años donde casi sólo había que preocuparse por crear un fichero ejecutable para su correspondiente plataforma.

Hoy por hoy nos encontramos que cualquier mínimo software involucrará aplicaciones de escritorio, applets o RIAs, contenedores web, servidores de aplicaciones, sistemas de mensajería, interfaces o servidores de terceros, etc. Asimismo, la integración continua (incluso aunque nos ponga en evidencia) se ha convertido en una práctica fundamental a la hora de lanzar software a tiempo. Sin embargo, está claro que a medida que el software se hace cada vez más y más complejo el mantener este proceso de integración continua se hace más complicado. Y es que hay que tener en cuenta que el proceso de integración continua no se limita únicamente a compilar el código fuente y asegurarse de que no se ha roto la build , si no que es necesario construir un sistema "vivo" que nuestro departamento de QA pueda utilizar para asegurarse de que realmente no se ha roto nada.

Para intentar solucionar este problema se introduce el rol de build/release engineer. Hoy por hoy si se busca en los portales de empleo se encuentran ofertas de empresas que buscan cubrir este tipo de vacante, aunque es cierto que tampoco son demasiadas. Por ejemplo hoy he estado buscando en las ofertas de Irlanda y sólo he encontrado tres o cuatro en el portal que suelo seguir.

La verdad es que por experiencia propia puedo decir que aunque el rol está justificado lo cierto es que es complicado encontrar a alguien que se quiera dedicar exclusivamente a mantener la salud del sistema de automatización de una empresa, por mucho que este rol te permita aprender como funcionan internamente muchos sistemas. Al fin y al cabo, quién quiere pasarse meses pelando con scripts y ficheros XML, ¿no?

Por lo tanto, en el caso de reconocer el valor de build engineer y no poder contratar a uno, ¿qué se puede hacer? Básicamente se me ocurren dos soluciones:

• Promocionar a alguien de QA: Normalmente (al menos aquí) los testers suelen ser graduates o personas con conocimientos informáticos pero que nunca se han dedicado a programar o que ni siquiera han estudiado realmente informática. Muchas de estas personas son realmente buenos en lo que hacen y llegan a tener un conocimiento global del funcionamiento del sistema mucho mejor que muchos desarrolladores.
  
  Algunos de estos testers con el tiempo van ganando experiencia y conocimientos que les permitirían pasar a ejercer un rol de build engineer, que a fin de cuentas está directamente relacionado con todo el proceso de QA, así que podría verse como un tipo de promoción natural.


• Asignar el rol de build engineer a todo el equipo: Para mi es importante resaltar aquí lo de "todo el equipo". Ya que todos sabemos lo que va a pasar si un desarrollador se dedica a configurar la build el sólo, es decir, que se convertirá de manera no-oficial en el build engineer, y que siempre que pase algo acudiremos a él a ver si lo puede solucionar.
  
  Rotando el rol de build-engineer entre los diferentes miembros del equipo, por ejemplo haciendo que cada semana uno ejerza ese papel, se consigue que todo el mundo acabe por tener un conocimiento de la build y que se mejore también el conocimiento global de como funciona el sistema. Al principio puede hacerse tedioso y engorroso, por eso de que todos tenemos muchas cosas que hacer para andar aprendiendo todos lo mismo, pero con el tiempo y cuando los errores aparezcan todo el grupo habrá adquirido el conocimiento para solucionar los problemas de automatización y no se dependerá del release engineer que vuelve dentro de un mes y se ha ido de vacaciones.

Por cierto, que si os lo estáis preguntando, pues nosotros por ahora nos hemos quedado en un termino medio. Cuando llegué no había nada de nada, pasados unos meses conseguimos un build engineer, pero con el tiempo lo perdimos, y ahora, pues bueno, como al final nuestra automatización ha llegado a niveles bastante avanzados y es bastante compleja pues requiere mucha dedicación, así que hay un equipo digamos de "gestión de procesos" que se dedica a controlarla, siendo algunos de los miembros de este equipo también desarrolladores. Es decir, que en lugar de involucrar a todos los desarrolladores lo que puede ser un poco utópico pues se escogen a tres o cuatro y se les asigna la responsabilidad de estar pendientes de eso como parte de su tiempo.