Entendiendo que somos una organización en que la tecnología tiene una influencia tan importante en la manera en que sus servicios interactúan con el cliente, y que buena parte de lo desarrollado por las diferentes células tienen un impacto en esta influencia, es que hemos definido junto a los Líderes Técnicos un contrato social algunos acuerdos básicos de trabajo, los cuales son los siguientes:

Perfilamiento de Usuarios: Todo Colaborador Interno de SMU será considerado como Member. Todo Partner de SMU (Agencias, Vendors, Consultores) será considerado como Outside Collaborator.

Cultura DevOps

Todos somos integrantes de un gran equipo, los cuales debemos asegurar de proveer a la organización y a sus clientes de un servicio de calidad. Para ello, los desarrolladores deben ser responsables de las soluciones de software que implementen, desde su concepción hasta su operación; y los especialistas de infraestructura deben proveer soluciones que habiliten a los desarrolladores a ser más eficientes con una serie de herramientas y procesos que automaticen la puesta en producción y operación.

Es por ello que si bien se pueden tener responsabilidades diferentes, no significa que no debamos comunicarnos, y por ello, es tan importante romper los silos funcionales y permitir el flujo de experiencias y de comunicación entre todos.

Custodia del código

Se considera como fuente autoritativa de código lo existente en GitHub, y por lo tanto este pasa a ser el lugar de custodia del código, tanto el código que está en producción como el que está en desarrollo. Cómo organización, utilizaremos las diferentes herramientas y capacidades que nos brinda GitHub (tanto propias, como de terceros y desarrolladas por nosotros mismos) para lograr un repositorio de código desde el cual se disparen los procesos de compilación y despliegue que, al ser automatizados, permitan una disminución en el tiempo del proceso.

GitOps

Dentro de DevOps, existe la filosofía de GitOps que dice que Git es la fuente absoluta de la verdad dentro de un sistema, por lo tanto, se requiere que la descripción de los estados deseados deban ser hechos mediante especificaciones declarativas, que se mantengan mediante un control de versiones; de manera de poder identificar que, cuando y quien hizo cierto cambio. Esto permite a los desarrolladores realizar labores relacionadas en la operación, de manera de cumplir el principio de usted lo crea, usted lo opera. Mas información aquí

Aspectos Técnicos

Para asegurar que los servicios entregados cumplen con los aspectos de calidad, debemos cumplir con lo siguiente:

Observabilidad

Es importante conocer en cada momento el estado interno de los sistemas, mediante una solución centralizada que permita, en una sola vista conocer el comportamiento actual de los sistemas. Es por ello que es necesario contar con mecanismos de generación de logs en las aplicaciones, así como un manejo adecuado de errores. Para ello es importante contar con:

Reporte de Salud

La aplicación debe tener un punto de entrada que reporte la salud de la aplicación. Normalmente expone la ruta /checkout/v1/healthcheck en la cual el sistema responde con un código HTTP 200, y de texto puede ser cualquiera, por ejemplo “OK”. Esto permitirá a los equipos de despliegue conocer si la aplicación sube correctamente, y si la misma se encuentra activa.

Respuestas de los microservicios REST

Tanto las respuestas esperadas, como los errores deben seguir el estandar de los servicios REST. Se puede revisar un ejemplo del mismo aquí

Seguridad

Todo servicio debe cumplir con los siguientes acuerdos básicos de seguridad:

No debe exponerse información sensible en el código
Toda información sensible debe ser cifrada
En caso de claves y tokens debe ser guardados en el servicio provisto para ello
Se debe asegurar que las imágenes y paquetes usados no tengan vulnerabilidades

Nombre de los Repositorios

De manera de estandarizar los procesos, y poder organizar los diferentes proyectos, se debe usar esta nomenclatura para los nombres de los repositorios:

Nomenclatura	Descripción	Ejemplo
fe-<nombre>	Front End	fe-unimarc
be-<nombre>	Back End	be-unimarc
bff-<nombre>	Back End For Frontend	bff-unimarc
db-[fe\|be\|bff\|tool]-<nombre>	Scripts de Base de Datos	db-bff-unimarc db-be-unimarc
app-[ios\|and\|hyb\|vtx]-<nombre>	Código para aplicaciones	app-ios-unimarc app-and-unimarc app-vtx-promocion
pkg-<nombre>	Package	pkg-headless
tool-<nombre>	Herramientas	tool-onboarding
terraform-<nombre>	Infraestructura como Código	terraform-cluster
dataform-<Nombre de proyecto>-<Nombre de artefacto>	Módulos de Dataform	dataform-clientes360

Cobertura de Bugs

Para los bugs hemos definido, que todo proyecto en Github no debe comprometer ningún bug con severidad Blocker, Critical ni Major, los cuales incluso podrían condicionar la aprobación de un Pull Request

Mas información aquí

Cobertura de Vulnerabilities

Para vulverabilities hemos definido, que todo proyecto en Github no debe comprometer ninguna vulnerabilidad, siendo nuestra tolerancia cero dado que nuestro compromiso con la seguridad de nuestro software. Para complementar esta declaración, Sonarqube nos entrega feedback basado en los siguientes criterios de análisis:

SonarSource : Para mas información aquí
OWASP Top 10 : Para mas información aquí
SANS Top 25 : Para mas información aquí
CWE : Para mas información aquí

Cobertura de Security Hotspots

Un Security Hotspots resalta un fragmento de código sensible a la seguridad que el desarrollador debe revisar. Tras la revisión, descubrirá que no hay amenaza o que necesita aplicar una solución para proteger el código./

Para Security Hotspots hemos definido, que todo proyecto en Github no debe comprometer ningun Security Hotspots, siendo nuestra tolerancia cero dado que nuestro compromiso con la seguridad de nuestro software.

Mas información aquí

Revisión de secretos expuestos

Otra parte importante del análisis de seguridad tiene que ver con el análisis de información sensible en el código como contraseñas en texto plano, token de autenticación, etc. Estos secretos que puedan estar definidos en el código pueden ser ubicados gracias al uso de trufflehog, el cual se encarga de analizar si existe algún secreto en alguno de los commits hechos en el repositorio. En este caso la solución es la eliminación del commit o de los commits ofensores del repositorio.

Mas información aquí