La práctica DevOps no es cosa nueva para Base22. Como firma tenemos más de 15 años de experiencia y hay en el equipo miembros que han estado haciendo código durante mucho más tiempo que eso. Como proveedor de servicios tecnológicos, hemos podido desarrollar un conjunto de prácticas probadas y herramientas en torno a DevOps (desarrollo de software/operaciones). La aparición de herramientas e infraestructura basadas en la nube nos ofrece mucha flexibilidad en el desarrollo y la implementación de aplicaciones.
Nuestros clientes ahora nos piden ayuda con su propia especialidad emergente de DevOps y realmente esto se ha convertido en una vía de doble sentido: compartimos las lecciones aprendidas y crecemos de forma colectiva en nuestros conocimientos sobre la práctica DevOps. Existe también un impulsor adicional para nuestro enfoque y es el desarrollo de nuestra plataforma de aplicación Carbon LDP. Por lo tanto, el desarrollo de productos de Base22 junto con nuestro trabajo de desarrollo de aplicaciones para clientes, ha acelerado nuestra adopción de DevOps.
Te presentamos un resumen de nuestro punto de vista actual sobre la práctica DevOps. Nuestra historia continuará evolucionando, pero por ahora, queremos compartirte dónde nos encontramos con la esperanza de que esta información pueda serte útil.
Componentes de la práctica DevOps
Para Base22, agrupamos nuestras herramientas y procesos en los siguientes componentes:
- Colaboración y planificación de proyectos
- Control de origen
- Estructura de la automatización
- Pruebas automatizadas
- Despliegue automatizado
- Gestión de salud ambiental
Analicemos cada uno de estos componentes.
Colaboración y planificación de proyectos
Hay una variedad de conjuntos de herramientas para facilitar la colaboración y la planificación de proyectos, estas son algunas de nuestras favoritas y así es cómo los usamos:
Set de herramientas | Cómo las usamos |
JIRA (de Atlassian) | - Herramienta basada en la web para el seguimiento de problemas/tareas en TODOS los proyectos
- Knowledge base consultable en todos los engagements
- Podemos actualizar las tareas de JIRA mencionando sus ID en los mensajes de confirmación del código fuente
|
Confluence (de Atlassian) | - Repositorio wiki basado en la web para TODOS los proyectos
- Fuente única de verdad para la documentación relacionada con el proyecto
|
Slack | - Mensajería instantánea y colaboración entre miembros del equipo interno y del cliente
- Se puede compartir fácilmente fragmentos de código
- Gran capacidad de búsqueda
|
GitHub | - Hospeda repositorios git públicos/privados
- Seguimiento de problemas
- Pull requests/revisión de código. La interfaz de usuario de GitHub se destaca por esto
- Documentación del proyecto usando:
- para el JS SDK.
- Descubrimos que mantener la documentación dentro de cada repositorio (junto con el código) es la mejor opción porque proporciona un mejor contexto y seguimiento a cambios.
- Proyectos de GitHub. Creamos tableros que se pueden configurar para satisfacer nuestras necesidades.
|
WaffleIO | - Una herramienta automatizada para la gestión de proyectos, accionada por problemas en GitHub y pull requests
- Hacemos un seguimiento de los problemas de GitHub en varios proyectos y la herramienta automatiza su estatus (después de que un desarrollador crea una ramificación con el número de problema, WaffleIO establece el problema como “En progreso”)
|
Control de origen
Hay una serie de opciones que abordan los requisitos de nuestra fuente de control. Estas son nuestras herramientas actuales:
| Set de herramientas | Cómo las usamos |
BitBucket (de Atlassian) | - Nuestro repositorio principal de código fuente que compartimos con todos nuestros clientes
- La integración con otros productos de Atlassian y otras herramientas es una verdadera ventaja (ej. actualización de tareas JIRA desde operaciones de código fuente)
|
GitHub | - Hospeda repositorios git públicos/privados
- Pull requests/revisión de código. La interfaz de usuario de GitHub se destaca por esto
|
Estructura de la automatización
Set de herramientas | Cómo las usamos |
Docker Cloud | - Nos ayuda a automatizar el proceso de compilación comenzando con el código fuente y concluyendo con las imágenes de Docker
- Lo usamos para crear nuevas imágenes automáticamente cada vez que etiquetamos un commit en un repositorio de git rastreado
- Ejemplo: etiquetamos un commit en la plataforma como v1.0.1, entonces Docker Cloud recibe una notificación sobre el cambio y activa su proceso de compilación automatizado. Una vez que se completa, se publica una imagen en el centro de Docker (registro público de imágenes de Docker) con la misma etiqueta.
|
IBM Bluemix | - Hemos utilizado las tuberías de Bluemix para automatizar la construcción y las pruebas. Ofrecía mucha potencia, pero tenía algunas deficiencias, por lo que volveremos a utilizar Bluemix en el futuro (ejemplo: Bluemix no admitió la activación de diferentes tuberías desde diferentes ramas de git).
|
Jenkins | - Usamos Jenkins para extraer automáticamente la última versión del código fuente de una rama específica, para construir artefactos de software, y para implementar la integración y puesta en escena de los entornos en función de determinadas condiciones que el código debe cumplir (por ejemplo, indicadores que avisan si el código es una compilación para la depuración o prueba, o si está listo para la puesta en escena).
|
Pruebas automatizadas
A lo largo de la historia, las pruebas nos han consumido mucho tiempo, lo que ha resultado en que las organizaciones tomen atajos o simplemente las eliminen para poder cumplir con un cronograma, lo que ofrece resultados por debajo de lo óptimo cuando una solución se implementa en plena producción. Hay muchas opciones para automatizar las pruebas. Estas son algunas de nuestras favoritas:
Set de herramientas | Cómo las usamos |
Selenium | |
SortSite: Cumplimiento de la Sección 508 | - Hemos utilizado este conjunto de pruebas para verificar el cumplimiento de la Sección 508, así como otros problemas del sitio web
|
Junit | - Una opción para realizar pruebas unitarias en nuestro código Java
|
TestNG | - Otra opción que usamos para probar nuestro código Java
|
Travis CI | - Utilizamos este servicio en la nube para probar repositorios públicos. Cada vez que se crea un pull request, se activa una fase de prueba automatizada y, una vez que finaliza, Travis CI marca el compromiso de los RP como “fallido” o “aprobado”
- Los maintainers pueden confiar (o no) en que el código introducido funciona (o al menos pasa las pruebas)
|
Despliegue automatizado
Set de herramientas | Cómo las usamos |
Docker Cloud | - Configuramos Docker Cloud para implementar contenedores basados en las imágenes que crea para nuestros entornos. Además de implementar los contenedores, también organiza los servicios de múltiples nodos que hemos implementado y el intercambio de contenedores
|
IBM Bluemix Pipelines | - Hemos utilizado tuberías de Bluemix para automatizar la implementación del código en nuestras instancias públicas
- Después de crear imágenes de Docker, Bluemix Pipelines realizó un red-black deployment en nuestros servidores
|
Para más información sobre nuestra práctica DevOps
Nos encantaría saber de ti. Si has tenido aprendizajes de la práctica de DevOps que te gustaría compartir, o tal vez saber más sobre nuestras experiencias, ponte en contacto con nosotros.
