Bueno, lo primero es lo primero: este post no es la verdad absoluta, así que si vienes en busca de iluminación, espero que esta entrada sirva como punto de partida, pero te recomendaría leer todo lo posible sobre este tema, empezando por consultar los enlaces del final del post.
Por mi parte, con esta entrada he querido resumir los conceptos principales de cada una de estas prácticas, para intentar aclarar(me) con las diferencias entre ellas.
Integración Continua
Los equipos de desarrollo de software que trabajan en un mismo proyecto, suelen encontrarse a menudo con los siguientes problemas:
- Merge conflicts: dos programadores modifican el mismo fichero o incluso la misma línea, lo cual da lugar a conflictos que deben resolverse y que pueden llegar a ser un quebradero de cabeza.
- Compile conflicts: si por ejemplo un programador usa el método foo() y alguien elimina ese método, ésto no dará problemas al hacer el merge, pero a nivel de compilación dará error porqué no encontrará ese método.
- Test conflicts: un ejemplo de test conflict sería cuando tu código depende de otro que ha cambiado (y ahora funciona diferente), lo cual haría que tu código no esté funcionando como esperabas y por tanto tu código no pase los tests.
La integración continua es una práctica de desarrollo de software que pretende minimizar este tipo de conflictos, permitiendo a las desarrolladores desarrollar, en lugar de perder su tiempo solucionando conflictos. La idea básica es que los desarrolladores commiteen los cambios muy frecuentemente (al menos una vez al día) para que en caso de conflicto se puedan solucionar de forma más rápida y sencilla, pues el propio programador tendrá el código que acaba de commitear “fresco” en su cabeza, y además no tendrá que preocuparse de investigar grandes cantidades de código, pues al commitear muy frecuentemente sabe que ha cambiado poco código desde su anterior commit.
La integración contínua, pues, consiste en automatizar los tests y los builds de tu software muy frecuentemente. A no ser que seas el único desarrollador en un proyecto, no hay razón por la que no quieras usar integración continua.
Continuar leyendo «Integración Continua vs Continuous Delivery vs Continuous Deployment»
¿Por qué Zabbix?
JBoss es un Servidor de Aplicaciones Java completo, de código abierto, desarrollado por Red Hat. Y sí, yo también pienso en Apache Tomcat en estos momentos, pero hay diferencias entre ellos explicadas por ejemplo 
Si contamos con un servidor Apache, quizá nos interese pasarlo a nginx con el menor downtime posible. Yo he hecho alguna prueba partiendo del siguiente entorno:
He querido recoger algunas notas de Bash scripting para no tener que correr a Google (o a cualquier página de StackExchange) cada vez que las dudas me asalten.
Hace ya unos años, y sin ningún software de administración tipo Puppet/Chef/Ansible, creamos un documento para que todos los técnicos pudieran decir la suya respecto a los pasos a dar tras instalar un sistema operativo Linux (CentOS en nuestro caso), con tal de no olvidarnos ninguno e ir mejorando entre todos este proceso de configuración inicial de un servidor. Eso significa que si tú, amado lector, tienes cualquier sugerencia de mejora, no dudes en dejarla en los comentarios.
Como viene siendo habitual, llega el post resumen del año pasado, con el que pretendo mostrar de forma transparente los números de helloit.es.
Otro post que tenía en borradores y que he decidido rescatar. Esta vez sobre hardware, con comandos tan básicos como útiles.
WordPress va genial, pero todo sea dicho, también puede ser un coladero si no se ponen medidas para hacerlo seguro. A continuación listo algunas de las medidas que se podrían aplicar para empezar a hacer de nuestro site, un sitio más seguro.
Este es mi resumen de la parte de Scrum (sin incluir XP) del libro «