DevOps de Base22: una historia en evolución

Base22 ha existido desde hace más de 10 años 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 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 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 DevOps

Para Base22, agrupamos nuestras herramientas y procesos en los siguientes componentes:

  1. Colaboración y planificación de proyectos
  2. Control de origen
  3. Estructura de la automatización
  4. Pruebas automatizadas
  5. Despliegue automatizado
  6. 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:
    • Páginas de GitHub 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

  • Una herramienta excepcional basada en el navegador para ejecutar scripts de prueba funcionales
  • Video resumen sobre Selenium (Cody Burleston)

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

Nos encantaría saber de ti. Si has tenido aprendizajes de DevOps que te gustaría compartir, o tal vez saber más sobre nuestras experiencias, ponte en contacto con Xavier Muñiz o Anson Call.

475 316 Mike Minardi
Start Typing