Díganos qué opina sobre la experiencia de descarga del PDF.

Centro de recursos de DevOps

Artículo • 11/09/2023

Este centro ofrece recursos sobre procedimientos de DevOps, métodos ágiles, control
de versiones de Git, DevOps en Microsoft y cómo evaluar el progreso de DevOps de su
organización.

Planificar con DevOps

Amplíe la capacidad de sus equipos para que administren el trabajo con agilidad y
visibilidad total de los productos y los proyectos.

Desarrollar con DevOps

Aproveche las herramientas principales de DevOps como Git para administrar de
manera eficiente el proceso de desarrollo.
Entregar con DevOps
Implemente aplicaciones en cualquier plataforma y aporte valor de forma continua al
cliente a través de pruebas automatizadas.

Operar con DevOps

Implemente la supervisión de pila completa, reciba alertas ejecutables y obtenga
información detallada de los registros y la telemetría para poner en marcha los sistemas
de producción con facilidad.

Eventos y charlas de DevOps

Vea algunas charlas de conferencias recientes sobre Devops en el canal de YouTube de
Microsoft.
Herramientas de DevOps
GitHub
Implemente procedimientos recomendados de DevOps, como control de versiones,
codificación colaborativa, automatización, CI/CD, seguridad y administración de equipos
con GitHub.

Azure DevOps
Haga uso de la administración de proyectos, el diseño y la ingeniería con procesos
integrados y colaborativos para planificar el trabajo, desarrollar el código y lanzar las
aplicaciones.

CLI de desarrollo de Azure

Use estos comandos descriptivos para desarrolladores para disfrutar de un sistema
uniforme en el terminal, el editor de código o el entorno de desarrollo integrado y el
canal de Acciones de GitHub.

Visual Studio
Use este entorno de desarrollo integrado (IDE) para crear aplicaciones eficaces y
escalables de Azure.

Visual Studio Code

Use este editor de código fuente ligero pero eficaz en equipos Windows, macOS y Linux.
¿Qué es DevOps?
Artículo • 05/10/2023

DevOps es una combinación de desarrollo (Dev) y operaciones (Ops) para unir personas,
procesos y tecnología en el planeamiento, desarrollo, entrega y operaciones de las
aplicaciones. DevOps facilita la coordinación y colaboración entre funciones que antes
estaban aisladas, como el desarrollo, las operaciones de TI, la ingeniería de calidad y la
seguridad.

Los equipos adoptan una cultura de DevOps junto con las prácticas y herramientas para
aumentar la confianza en las aplicaciones que compilan, responden mejor a las
necesidades de los clientes y logran sus objetivos empresariales más rápidamente.
DevOps permite a los equipos ofrecer continuamente valor a los clientes mediante la
creación de productos mejores y más fiables.

DevOps y el ciclo de vida de las aplicaciones

DevOps influye en el ciclo de vida de las aplicaciones a lo largo de las fases de
planeamiento, desarrollo, entrega y operaciones. Cada fase se basa en las demás y las
fases no son específicas de un rol. Una cultura DevOps implica a todos los roles en cada
fase hasta cierto punto.

En el diagrama a continuación se muestran las fases del estilo de vida de la aplicación

DevOps:
Objetivos y ventajas de DevOps
Cuando un equipo adopta la cultura, las prácticas y las herramientas de DevOps, puede
conseguir resultados increíbles:

Reducir el tiempo de comercialización

Gracias al aumento de la eficacia, la mejora de la colaboración en equipo, las
herramientas de automatización y la implementación continua, los equipos pueden
reducir con rapidez el tiempo que transcurre desde la creación del producto hasta su
lanzamiento al mercado.
Adaptación al mercado y a la competencia
Una cultura de DevOps exige equipos orientados al cliente. La combinación de agilidad,
colaboración en equipo y atención a la experiencia del cliente permite a los equipos
ofrecer continuamente valor a sus clientes y aumentar su competitividad en el mercado.
Mantenimiento de la estabilidad y la confiabilidad del
sistema
Mediante la adopción de prácticas de mejora continua, los equipos son capaces de
aumentar la estabilidad y fiabilidad de los productos y servicios que implementan. Estas
prácticas facilitan la reducción de errores y de riesgo.
Mejora del tiempo medio de recuperación
La métrica tiempo medio de recuperación indica cuánto tiempo toma la recuperación de
un error o una vulneración. Para administrar errores de software, vulneraciones de
seguridad y planes de mejora continua, los equipos deben medir y trabajar para mejorar
esta métrica.

Adopción de una cultura de DevOps

Para implementar completamente DevOps, debe adoptar una cultura de DevOps.
Cultivar una cultura de DevOps requiere cambios profundos en la forma en la que las
personas trabajan y colaboran. Cuando las organizaciones se comprometen a
implementar una cultura de DevOps, crean un entorno que facilita la evolución de
equipos de alto rendimiento. Si bien la adopción de prácticas de DevOps automatiza y
optimiza los procesos a través de la tecnología, sin un cambio hacia una cultura de
DevOps dentro de la organización y su personal, no se obtendrán todas las ventajas de
DevOps.

En la imagen a continuación se capturan aspectos esenciales de la cultura del sitio web

en directo de Microsoft.

Los procedimientos a continuación son componentes esenciales de la cultura de

DevOps:

Colaboración, visibilidad y alineación: un rasgo distintivo de una cultura de

DevOps saludable es la colaboración entre equipos. La colaboración comienza con
la visibilidad. Los equipos de desarrollo, TI y otros deben compartir entre sí los
procesos, prioridades y preocupaciones en materia de DevOps. Al planear el
trabajo juntos, están en mejores condiciones de alinearse con los objetivos y las
medidas de éxito en relación con la empresa.
Cambios en alcance y responsabilidad: a medida que los equipos se alinean,
asumen y participan en otras fases del ciclo de vida, no solo las que son principales
para su rol. Por ejemplo, los desarrolladores asumen responsabilidad no solo por la
innovación y la calidad establecidas en la fase de desarrollo, sino también por el
rendimiento y la estabilidad que sus cambios producen en la fase de uso. Al mismo
tiempo, los operadores de TI se aseguran de incluir la gobernanza, la seguridad y
el cumplimiento normativo en las fases de planeamiento y desarrollo.
Ciclos de lanzamiento más cortos: los equipos de DevOps mantienen la agilidad
porque lanzan versiones de software en ciclos cortos. Los ciclos de lanzamiento de
versiones más cortos facilitan el planeamiento y la administración de los riesgos,
porque el progreso es incremental, lo que reduce el impacto en la estabilidad del
 sistema. El acortamiento de los ciclos de lanzamiento de versiones permite
también a las organizaciones adaptarse y reaccionar a las necesidades cambiantes
de los clientes y a la presión competitiva.
Aprendizaje continuo: los equipos de DevOps de alto rendimiento establecen una
mentalidad de crecimiento. Fracasan rápido e incorporan los aprendizajes a los
procesos. Se esfuerzan por mejorar constantemente, aumentar la satisfacción del
cliente y acelerar la innovación y la adecuación al mercado.

Implementación de procedimientos de DevOps

Se implementa DevOps al seguir las prácticas de DevOps (descritas en las secciones
siguientes) a lo largo del ciclo de vida de la aplicación. Algunas de estas prácticas
ayudan a agilizar, automatizar y mejorar una fase específica. Otras abarcan varias fases y
ayudan a los equipos a crear procesos homogéneos que favorezcan la productividad.

Integración continua y entrega continua (CI/CD)

La integración continua (CI) es la práctica que utilizan los equipos de desarrollo para la
automatización, combinación y prueba de código. La integración continua ayuda a
detectar errores en etapas tempranas del ciclo de desarrollo, lo que hace que sean
menos costosos de corregir. Las pruebas automatizadas se ejecutan como parte del
proceso de CI para garantizar la calidad. Los sistemas de CI generan artefactos y los
alimentan para liberar procesos a fin de impulsar implementaciones frecuentes.

La entrega continua (CD) es un proceso por el que el código se compila, prueba e

implementa en uno o varios entornos de prueba y producción. La implementación y las
pruebas en varios entornos aumentan la calidad. Los sistemas de CD generan artefactos
que se pueden implementar, incluida la infraestructura y las aplicaciones. Los procesos
de versión automatizados consumen estos artefactos para publicar versiones nuevas y
correcciones en los sistemas existentes. Los sistemas que supervisan y envían alertas se
ejecutan de manera continua para impulsar la visibilidad de todo el proceso de CD.

Control de versiones
Control de versiones es la práctica de administrar el código por versiones, haciendo un
seguimiento de las revisiones y del historial de cambios para facilitar la revisión y la
recuperación del código. Esta práctica suele implementarse con sistemas de control de
versiones, como Git, que permite que varios desarrolladores colaboren para crear
código. Estos sistemas proporcionan un proceso claro para fusionar mediante
combinación los cambios en el código que tienen lugar en los mismos archivos,
controlar los conflictos y revertir los cambios a estados anteriores.

El uso del control de versiones es una práctica de DevOps fundamental que ayuda a los
equipos de desarrollo a trabajar juntos, dividir las tareas de programación entre los
miembros del equipo y almacenar todo el código para poder recuperarlo fácilmente si
fuese necesario. El control de versiones es también un elemento necesario en otras
prácticas, como la integración continua y la infraestructura como código.

Desarrollo ágil de software

Agile es un enfoque de desarrollo de software que resalta la colaboración en equipo, los
comentarios de los clientes y los usuarios, y la alta capacidad de adaptación al cambio a
través de ciclos de versión cortos. Los equipos que practican la metodología ágil
proporcionan mejoras y cambios continuos a los clientes, recopilan sus comentarios y,
después, aprenden y ajustan el software en función de lo que el cliente quiere y
necesita. El método ágil es muy diferente a otros marcos más tradicionales, como el
modelo en cascada, que incluye ciclos de lanzamiento de versiones largos definidos por
fases secuenciales. Kanban y Scrum son dos marcos populares asociados al método ágil.

Infraestructura como código

La infraestructura cómo código define las topologías y los recursos del sistema de un
modo descriptivo que permite a los equipos administrar esos recursos igual que lo
harían con el código. Las diferentes versiones de esas definiciones se pueden almacenar
en sistemas de control de versiones, donde se pueden revisar y revertir, de nuevo, igual
que el código.

La práctica de la infraestructura como código permite a los equipos implementar

recursos del sistema de un modo confiable, repetible y controlado. Además, la
infraestructura como código ayuda a automatizar la implementación y reduce el riesgo
de errores humanos, especialmente en entornos complejos de gran tamaño. Esta
solución repetible y confiable para la implementación de entornos permite a los equipos
mantener entornos de desarrollo y pruebas que sean idénticos al entorno de
producción. De igual modo, la duplicación de entornos en otros centros de datos y en
plataformas en la nube es más sencilla y más eficiente.

Administración de configuración
La administración de configuración hace referencia a la administración del estado de los
recursos en un sistema, incluidos servidores, máquinas virtuales y bases de datos. El uso
de herramientas de administración de la configuración permite a los equipos distribuir
cambios de un modo controlado y sistemático, lo que reduce el riesgo de modificar la
configuración del sistema. Los equipos utilizan herramientas de administración de la
configuración para hacer un seguimiento del estado del sistema y evitar alteraciones en
la configuración, que es como se desvía la configuración de un recurso del sistema a lo
largo del tiempo del estado definido para él.

Junto con la infraestructura como código, resulta fácil elaborar plantillas y automatizar la
definición y la configuración de sistemas, lo que permite a los equipos usar entornos
complejos a escala.

Supervisión continua
La supervisión continua supone tener una visibilidad completa y en tiempo real del
rendimiento y el estado de la totalidad de las aplicaciones. La visibilidad abarca desde la
infraestructura de base que ejecuta la aplicación hasta los componentes de software de
nivel superior. La visibilidad se logra mediante la recopilación de datos de telemetría y
metadatos y el establecimiento de alertas para condiciones predefinidas que garanticen
la atención de un operador. La telemetría incluye registros y datos de eventos
recopilados de varias partes del sistema que se almacenan donde pueden analizarse y
consultarse.

Los equipos de DevOps de alto rendimiento se aseguran de establecer alertas útiles que
les permitan tomar medidas y recopilan datos de telemetría muy completos para
obtener conclusiones a partir de enormes cantidades de datos. Estas conclusiones
ayudan a los equipos a mitigar los problemas en tiempo real y a ver cómo mejorar la
aplicación en futuros ciclos de desarrollo.

Planificación
En la fase de planeamiento, los equipos de DevOps conciben, definen y describen las
características y la funcionalidad de las aplicaciones y los sistemas que planean crear.
Los equipos realizan el seguimiento del progreso de tareas en niveles bajos y altos de
granularidad desde productos individuales a carteras de varios productos. Los equipos
utilizan las siguientes prácticas de DevOps para establecer planes con agilidad y
visibilidad:

Creación de trabajo pendiente.

Seguimiento de errores.
Administración del desarrollo de software Agile con Scrum.
Uso de paneles Kanban.
 Visualización del progreso con paneles.

Para obtener una visión general de las distintas lecciones aprendidas y prácticas que
Microsoft adoptó para admitir el planeamiento de DevOps en todos los equipos de
software de la empresa, consulte Cómo Microsoft planea con DevOps.

Desarrollo
La fase de desarrollo comprende todos los aspectos del desarrollo de código de
software. En esta fase, los equipos de DevOps llevan a cabo las tareas a continuación:

Selección de un entorno de desarrollo.

Escritura, prueba, revisión e integración del código.
Compilación del código en artefactos para implementarlo en diferentes entornos.
Uso de control de versiones, normalmente Git, para colaborar en el código y
trabajar en paralelo.

Para innovar con rapidez sin sacrificar la calidad, la estabilidad ni la productividad, los
equipos de DevOps:

Utilizan herramientas altamente productivas.

Automatizan los pasos cotidianos y manuales.
Realizan iteraciones en incrementos pequeños mediante pruebas automatizadas e
integración continua (CI).

Para obtener información general sobre las prácticas de desarrollo que Microsoft
adoptó para admitir su cambio a DevOps, consulte Cómo microsoft se desarrolla con
DevOps.

Entrega
La entrega es el proceso de implementación de aplicaciones en entornos de producción
de forma coherente y confiable, idealmente mediante la entrega continua (CD).

En la fase de entrega, los equipos de DevOps:

Establecen un proceso de administración de versiones con etapas de aprobación

manual claras.
Configuran puertas automatizadas para mover aplicaciones entre fases hasta la
versión final a los clientes.
Automatizan los procesos de entrega para que sean escalables, repetibles,
controlados y probados correctamente.
La entrega también implica la implementación y configuración de la infraestructura
fundamental del entorno de entrega. Los equipos de DevOps utilizan tecnologías como
infraestructura como código (IaC), contenedores y microservicios a fin de ofrecer
entornos de infraestructura totalmente regulados.

Las prácticas de implementación segura pueden identificar problemas antes de que

afecten a la experiencia del cliente. Estas prácticas ayudan a los equipos de DevOps a
realizar entregas con facilidad, confianza y tranquilidad.

Los principios y procesos básicos de DevOps que Microsoft ha evolucionado para

ofrecer sistemas de entrega eficientes se describen en Cómo Microsoft entrega software
con DevOps.

Operations
La fase de operaciones implica el mantenimiento, la supervisión y la solución de
problemas de aplicaciones en entornos de producción, que incluyen nubes híbridas o
públicas como Azure . Los objetivos de los equipos de DevOps son la confiabilidad del
sistema, la alta disponibilidad, la seguridad sólida y el tiempo de inactividad cero.

La entrega automatizada y las prácticas de implementación segura ayudan a los equipos

a identificar y paliar los problemas rápidamente cuando se producen. El mantenimiento
de la vigilancia requiere una telemetría muy completa, alertas que permitan tomar
medidas y visibilidad total de las aplicaciones y de los sistemas subyacentes.

Los procedimientos que Microsoft utiliza para operar plataformas en línea complejas se
describen en Cómo opera Microsoft en sistemas confiables con DevOps.

Pasos siguientes
Planee cargas de trabajo eficientes con DevOps
Desarrollo de software moderno con DevOps
Entregue servicios de calidad con DevOps
Opere en sistemas confiables con DevOps

Otros recursos
Soluciones de DevOps en Azure
El recorrido de DevOps en Microsoft
Comience a practicar DevOps con Azure
Seguridad en DevOps (DevSecOps)
Aprendizaje y certificaciones
Introducción a Azure DevOps
Introducción a DevOps Dojo: creación de métodos eficientes para el negocio
AZ-400: Introducción al recorrido por la transformación de DevOps
Comunicación y colaboración sencillas
Examen AZ-400: Designing and Implementing Microsoft DevOps Solutions
AZ-400: Implementación de seguridad y comprobación del cumplimiento de las de
bases de código
Planee cargas de trabajo eficientes con
DevOps
Artículo • 05/10/2023

La fase de planeamiento de DevOps suele considerarse la primera etapa de DevOps, lo

que no es del todo exacto. En la práctica, los equipos de software modernos trabajan en
ciclos ajustados en los que cada fase informa continuamente a las demás a través de las
lecciones que aprende.

A veces esos aprendizajes son positivos. A veces son negativos. Y a veces representan
información neutral que el equipo necesita para tomar decisiones estratégicas para el
futuro. El sector se ha unido en torno a un único término para describir la capacidad de
adaptarse rápidamente a las circunstancias cambiantes que crean estas lecciones: Agile.
El término se ha vuelto tan omnipresente que ahora es sinónimo de la mayoría de las
formas de planeamiento de DevOps.

¿Qué es Agile?
Agile se usa para describir un enfoque pragmático del desarrollo de software, y se
resaltan la entrega incremental y la colaboración en equipo, así como el planeamiento y
el aprendizaje continuos. No se trata de un conjunto específico de herramientas o
prácticas, sino de una mentalidad de planeamiento siempre abierta al cambio y al
compromiso.
Los equipos que utilizan las prácticas de desarrollo de Agile acortan su ciclo de vida de
desarrollo con el fin de generar software utilizable en un plazo coherente. La atención
constante a la calidad para los usuarios finales permite que el proyecto en su conjunto
se adapte rápidamente a la evolución de las necesidades. Para empezar a ver este tipo
de resultados, los equipos necesitan establecer algunos procedimientos en el camino.

Adopción de una cultura ágil

Crear y fomentar una cultura Agile dentro de una organización es una inversión clave
para lograr un devOps eficaz. Aunque el resultado final sea un conjunto específico de
software y servicios, los recursos humanos necesarios para producir y mantener esos
activos merecen una mención especial. Los equipos obtienen mejores resultados
cuando invierten tiempo en adaptar su cultura a los valores de la mentalidad Agile.

Selección de un método Agile

Los métodos Agile, que a menudo se denominan marcos, son enfoques integrales de las
fases del ciclo de vida del desarrollo de software. Establecen un método para realizar el
trabajo con directrices y principios claros. Uno de los marcos Agile más populares es
Scrum. La mayoría de los equipos que se inician en Agile empiezan con Scrum, debido a
su comunidad y ecosistema maduros. Pero existen muchas alternativas, así que merece
la pena tomarse el tiempo necesario para revisar las distintas opciones antes de
decidirse.

Adopción de herramientas Agile

Existe una industria sólida en torno a las herramientas para el planeamiento de DevOps.
Por lo general, estas herramientas se integran con diversos métodos y plataformas Agile
que se utilizan en el desarrollo de software. Una herramienta habitual es Kanban, que
ayuda a las organizaciones y a los equipos a visualizar el trabajo para planear mejor la
entrega.

Creación de equipos Agile

Los equipos funcionan mejor cuando todos tienen un rumbo claro. La adopción de un
método Agile puede ser de gran ayuda en este ámbito, ya que Agile mejora la
transparencia en DevOps. Pero también existen otras técnicas eficaces que se pueden
aplicar para mejorar el funcionamiento de los equipos a lo largo de los hitos del
proyecto. Cualquier organización puede beneficiarse de la creación de equipos
productivos y orientados al cliente.
Escalado de Agile a medida que crece la organización
A medida que Agile ha ido ganando popularidad, muchos estereotipos y malas
interpretaciones han ensombrecido su eficacia. Es fácil decir "Sí, estamos poniendo en
práctica Agile" sin ninguna responsabilidad. A medida que pasa el tiempo, es habitual
que se generen malos hábitos por diversos motivos, como malentendidos sobre el
propósito de Agile. A las pequeñas empresas les puede resultar fácil omitir algunos de
estos conceptos erróneos. Pero en operaciones de mayor envergadura, estos problemas
pueden convertirse en auténticos quebraderos de cabeza si no se abordan.
Afortunadamente, existen directrices útiles para escalar Agile a equipos grandes.

Pasos siguientes
Microsoft fue una de las primeras grandes empresas en adoptar DevOps para planear
proyectos de software a gran escala. Descubra cómo Microsoft planea en DevOps.

¿Busca una experiencia práctica de DevOps? Eche un vistazo a la ruta de aprendizaje

Evolución de las prácticas de DevOps. Principalmente se centra en Azure DevOps, pero
los conceptos y la experiencia se aplican del mismo modo al planeamiento en otras
plataformas DevOps, como GitHub.
¿Qué es Agile?
Artículo • 05/10/2023

El término Agile describe los enfoques para el desarrollo de software que resaltan la
entrega incremental, la colaboración en equipo, el planeamiento y el aprendizaje
continuos. El término Agile se acuñó en 2001, en el Manifiesto Agile . El manifiesto
estableció principios para un mejor enfoque para el desarrollo de software. En esencia,
el manifiesto declara cuatro valores que representan los cimientos del movimiento
Agile. Tal y como está redactado, el manifiesto afirma:

Hemos venido a valorar:

Individuos e interacciones sobre procesos y herramientas.

Software de trabajo sobre documentación general.
Colaboración con el cliente sobre negociación contractual.
Respuesta al cambio sobre seguimiento de un plan.

El manifiesto no implica que los puntos a la derecha de estas afirmaciones no sean

importantes o necesarios. Por el contrario, los elementos de la izquierda son
simplemente más importantes.

Técnicas y procedimientos Agile

Es importante entender que Agile no se trata de una cosa. Una persona no hace
Agile. Por el contrario, Agile es una mentalidad que impulsa un enfoque del desarrollo
de software. Dado que no existe un enfoque único que se adapte a todas las
circunstancias, el término Agile ha surgido para representar diversos métodos y
procedimientos que se ajustan a las declaraciones de valores del manifiesto.
Los métodos Agile, que se suelen conocer como marcos, son enfoques amplios de las
fases del ciclo de vida de las DevOps: planeamiento, desarrollo, entrega y operaciones.
Establecen un método para realizar el trabajo con directrices y principios claros.

Scrum es el marco Agile más habitual y con el que la mayoría de las personas se inicia.
Por otro lado, los procedimientos Agile son técnicas que se aplican durante las fases del
ciclo de vida de desarrollo de software.

Póker de planeamiento es una práctica de estimación colaborativa concebida

para animar a los miembros del equipo a compartir su comprensión de lo que
significa finalizado. Muchas personas consideran que el proceso es divertido, y se
ha demostrado que ayuda a fomentar el trabajo en equipo y a mejorar las
estimaciones.
La integración continua (CI) es una práctica habitual de ingeniería Agile que
consiste en integrar con frecuencia los cambios de código en la rama
principal. Una compilación automatizada comprueba los cambios. Como resultado,
hay una reducción de la deuda de integración y una rama principal continuamente
disponible.

Estas prácticas, como todas las prácticas Agile, llevan la etiqueta Agile, ya que son
coherentes con los postulados del manifiesto Agile.

Lo que Agile no es
A medida que Agile ha ido ganando popularidad, muchos estereotipos y malas
interpretaciones han ensombrecido su eficacia. Es fácil decir "Sí, estamos poniendo en
práctica Agile", sin ninguna responsabilidad. Teniendo esto en cuenta, piense en algunas
cosas que Agile no es.

Agile no es codificación de vaqueros . Agile no debe confundirse con un enfoque

del desarrollo de software del tipo "lo iremos descubriendo sobre la marcha". Una
idea como esa no podría estar más lejos de la verdad. Agile requiere una definición
de finalizado y de valor explícito que se entrega a los clientes en cada sprint. Si
bien Agile valora la autonomía de las personas y los equipos, hace hincapié en la
autonomía alineada para garantizar que la mayor autonomía produzca un mayor
valor.
Agile no funciona sin rigor ni planeamiento. Por el contrario, los métodos y
procedimientos Agile suelen resaltar la disciplina en el planeamiento. La clave está
en el planeamiento continuo a lo largo de todo el proyecto, no solo al principio. El
planeamiento continuo garantiza que el equipo pueda aprender del trabajo que se
ejecute. A través de este enfoque, se maximiza la rentabilidad de la inversión (ROI)
en planeamiento.
"Los planes son no valen nada, pero el planeamiento lo es todo". — Dwight D.
Eisenhower

Agile no es una excusa para la ausencia de una hoja de ruta. Este concepto
erróneo es probablemente el que más daño ha hecho al movimiento Agile en
general. Las organizaciones y los equipos que siguen un enfoque Agile saben
perfectamente hacia dónde se dirigen y los resultados que quieren
conseguir. Reconocer el cambio como parte del proceso es diferente de girar en
una nueva dirección cada semana, sprint o mes.
Agile no significa desarrollo sin especificaciones. En cualquier proyecto resulta
necesario mantener al equipo alineado en el por qué y el cómo es que se produce
el trabajo. Un enfoque Agile para las especificaciones incluye garantizar de que las
especificaciones tengan un tamaño adecuado y que reflejen la manera en que el
equipo secuencia y entrega el trabajo.
Agile no es incapaz de adaptarse al trabajo no planeado y a otras interrupciones.
Es importante finalizar los sprints en el plazo correspondiente. Pero que surja un
problema que desvíe el desarrollo no significa que un sprint tenga que fracasar.
Los equipos pueden planear las interrupciones designando recursos con antelación
para los problemas y los imprevistos. De este modo, pueden resolver esos
problemas sin perder de vista el desarrollo.
Agile no es inadecuado para las grandes organizaciones. Una queja habitual es
que la colaboración, un componente clave del método Agile, resulta difícil en
equipos grandes. Otra queja es que los enfoques escalables de Agile introducen
estructuras y métodos que ponen en riesgo la flexibilidad. A pesar de estos
conceptos erróneos, es posible escalar con éxito los principios de Agile. Para
obtener información sobre cómo sobreponerse a estas dificultades, consulte
Escalado de Agile en equipos grandes.
Agile no es ineficaz. Para responder a las necesidades cambiantes de los clientes,
los desarrolladores invierten tiempo en cada iteración para mostrar un producto
que funcione y obtener comentarios. Es verdad que estos esfuerzos reducen el
tiempo que dedican al desarrollo. No obstante, incorporar las necesidades de los
clientes desde el principio ahorra mucho tiempo más adelante. Cuando las
características se alinean con la perspectiva del cliente, los desarrolladores evitan
grandes revisiones a largo plazo.
Agile no es una mala opción para las aplicaciones actuales, que a menudo se
centran en el flujo de datos. Tales proyectos suelen implicar más cargas de trabajo
de modelado de datos y de extracción-transformación-carga (ETL) que de
interfaces de usuario. Esto hace difícil demostrar un software utilizable con una
programación coherente y ajustada. Ahora bien, si se ajustan los objetivos, los
desarrolladores pueden seguir aplicando un enfoque Agile. En lugar de trabajar
 para realizar las tareas en cada iteración, los desarrolladores pueden centrarse en
ejecutar experimentos de datos. En lugar de presentar un producto de trabajo
cada pocas semanas, pueden intentar comprender mejor los datos.

¿Por qué elegir Agile?

¿Por qué alguien consideraría aplicar un enfoque Agile? No caben dudas de que las
reglas del juego en torno a la creación de software han cambiado radicalmente en los
últimos 10-15 años. Muchas de las actividades se asemejan, pero el paisaje y los
entornos en los que las aplicamos son claramente diferentes.

Compare lo que supone comprar software hoy en día con lo que suponía a
principios de la década de 2000. ¿Con qué frecuencia la gente se dirige a la tienda
para comprar software empresarial?
Considere cómo se recogen las opiniones de los clientes sobre los productos.
¿Cómo entendía un equipo lo que la gente pensaba de su software antes de las
redes sociales?
Considere la frecuencia con la que un equipo desea actualizar y mejorar el
software que entrega. Las actualizaciones anuales ya no son viables frente a la
competencia moderna.

Diego Lo Guidice de Forrester lo expresa mejor en su blog: Transforming Application

Delivery (Octubre de 2020).

"Todo ha cambiado drásticamente. La sostenibilidad, además de verde y limpia,

significa que lo que creamos hoy tiene que poder cambiarse fácil y rápidamente
mañana. Los planes estratégicos son a corto plazo, y el planeamiento y el cambio
son continuos". — Diego Lo Guidice, Forrester

Las reglas han cambiado, y las organizaciones de todo el mundo adaptan ahora en
consecuencia su enfoque del desarrollo de software. Los métodos y prácticas de Agile
no prometen resolver todos los problemas. Pero sí prometen establecer una cultura y un
entorno en los que las soluciones surjan a través de la colaboración, el planeamiento y
el aprendizaje continuos, y el deseo de ofrecer software de alta calidad con mayor
frecuencia.

Pasos siguientes
La decisión de tomar la ruta Agile para el desarrollo de software puede ofrecer algunas
oportunidades interesantes para mejorar su proceso de DevOps. Una serie de
consideraciones esenciales se centra en cómo el desarrollo de Agile se compara y
contrasta con el enfoque actual de una organización.
¿Qué es el desarrollo de Agile?
Artículo • 05/10/2023

El desarrollo de Agile es un término que se usa para describir el desarrollo de software

iterativo. El desarrollo de software iterativo acorta el ciclo de vida de DevOps mediante
la ejecución en incrementos más pequeños, normalmente denominados sprints. Los
sprints suelen durar entre una y cuatro semanas. El desarrollo de Agile suele contrastar
con el desarrollo tradicional o en cascada, donde los proyectos más grandes se planean
por adelantado y se ejecutan siguiendo ese plan.

La entrega de código de calidad de producción en cada sprint requiere que el equipo de

desarrollo de Agile se haga responsable del ritmo acelerado. En todos los sprints, se
deben realizar la codificación, las pruebas y la comprobación de calidad. Si un equipo no
está bien organizado, los resultados pueden no estar a la altura de las expectativas.
Aunque estas decepciones ofrezcan grandes oportunidades de aprendizaje, es útil
aprender algunas lecciones clave antes de empezar.

En este artículo se desarrollan algunos factores clave para el éxito de los equipos de
desarrollo de Agile:

Optimización dinámica del trabajo pendiente

Integración temprana y frecuente
Reducción de la deuda técnica

Optimización dinámica del trabajo pendiente

Un equipo de desarrollo de Agile trabaja con requisitos de trabajo pendiente, a menudo
denominados casos de usuario. El trabajo pendiente tiene prioridad y los casos de
usuario más importantes se encuentran en la parte superior. El propietario del producto
posee el trabajo pendiente y agrega, cambia y vuelve a dar prioridad a los casos de
usuario en función de las necesidades del cliente.
Uno de los mayores obstáculos en la productividad de un equipo de desarrollo ágil es
un trabajo pendiente mal definido. No se puede esperar que un equipo entregue de
forma consistente software de alta calidad en cada sprint a menos que tenga requisitos
claramente definidos.

El propietario del producto debe asegurarse de que, en cada sprint, los ingenieros
dispongan de casos de usuario claramente definidos con los que trabajar. Los casos de
usuario en la parte superior del trabajo pendiente deben estar siempre listos para que el
equipo empiece a trabajar en ellos. Esto se conoce como optimización del trabajo
pendiente. Mantener el trabajo pendiente listo para un equipo de desarrollo de Agile
requiere esfuerzo y disciplina. Por suerte, la inversión merece la pena.

Al optimizar el trabajo pendiente, tenga en cuenta las siguientes consideraciones clave.

1. El análisis de los casos de usuario suele ser una actividad de larga duración. La
creación de interfaces de usuario sofisticadas, diseños de pantalla impactantes y
soluciones atractivas para el cliente requieren tiempo y energía. Los propietarios
de productos rigurosos revisan los casos de usuario con dos o tres sprints de
antelación. Consideran las iteraciones de diseño y las opiniones de los clientes.
Trabajan para garantizar de que cada caso de usuario sea algo que el equipo de
Agile esté orgulloso de entregar al cliente.

2. Un caso de usuario no se analiza a menos que el equipo lo indique. El equipo

debe revisar el caso de usuario y aceptar que está listo para trabajar en él. Si un
equipo no conoce el caso de usuario hasta el primer día de un sprint, es probable
que surjan problemas.

3. Los casos de usuario que se encuentran más abajo en el trabajo pendiente

pueden resultar ambiguos. No pierda tiempo analizando elementos de menor
prioridad. Céntrese en la parte superior del trabajo pendiente.
Realice la integración temprana y frecuente
La integración continua y la entrega continua (CI/CD) preparan al equipo para el ritmo
rápido del desarrollo de Agile. Tan pronto como sea posible, automatice los procesos de
creación, prueba e implementación. Establezca esa automatización como una de las
primeras tareas que el equipo aborde al iniciar un nuevo proyecto.

Con la automatización, el equipo evita procesos de implementación manual lentos,

propensos a errores y que requieren mucho tiempo. Dado que los equipos lanzan cada
sprint, no hay tiempo para realizar estas tareas manualmente.

La CI/CD también afectan a la arquitectura del software. Garantiza la entrega de

software compilable e implementable. Cuando los equipos implementan una
característica difícil de desplegar, se dan cuenta inmediatamente si la compilación y las
implementaciones fallan. La CI/CD obliga a un equipo a solucionar los problemas de
implementación a medida que se producen. Por lo tanto, el producto siempre está listo
para enviarse.

Hay algunas actividades clave de CI/CD que son de vital importancia para el desarrollo
eficaz de Agile.

1. Pruebas de unidad. Las pruebas unitarias son la primera protección contra el error
humano. Considere las pruebas unitarias como parte de la codificación.
Compruebe las pruebas con el código. Haga que las pruebas unitarias formen
parte de cada compilación. Las pruebas unitarias fallidas significan una
compilación también fallida.

2. Automatización de compilaciones. El sistema de compilación debe extraer de

forma automática el código y las pruebas directamente del control de código
fuente cuando se ejecute la compilación.
 3. Directivas de ramas y compilaciones. Configure directivas de ramas y
compilaciones para compilar de forma automática a medida que el equipo
comprueba el código en una rama específica.

4. Implementar en un entorno. Configure un canal de distribución que despliegue

automáticamente los proyectos compilados en un entorno que imite al de
producción.

Minimizar la deuda técnica

Cuando se trata de finanzas personales, es más fácil no endeudarse que salir de las
deudas. La misma regla se aplica con la deuda técnica. La deuda técnica incluye todo
aquello que el equipo deba abordar debido a los atajos que se tomaron previamente.
Por ejemplo, si tiene una programación apretada, es posible que sacrifique la calidad
para cumplir un plazo. La deuda técnica es el precio que se paga más adelante, cuando
se debe refactorizar el código para compensar esa falta de calidad. Algunos ejemplos
son las medidas para solucionar problemas de diseño, errores, rendimiento,
funcionamiento o accesibilidad, entre otros.

Estar al día con la deuda técnica requiere valentía. Hay muchas presiones para aplazar la
revisión del código. Es agradable trabajar en las características e ignorar las deudas. Por
desgracia, tarde o temprano alguien tiene que pagar la deuda técnica. Al igual que la
deuda financiera, la deuda técnica es más difícil de pagar cuanto más tiempo pase. Un
propietario de producto sensato trabaja con su equipo para asegurarse de que haya
tiempo para saldar la deuda técnica en cada sprint. Conseguir un equilibrio entre la
reducción de la deuda técnica y el desarrollo de características es una tarea difícil. Por
suerte, existen algunas técnicas sencillas para crear equipos productivos y orientados al
cliente.

Siempre sea Agile

Ser Agile significa aprender de la experiencia y mejorar continuamente. El desarrollo de
Agile ofrece más ciclos de aprendizaje que el planeamiento de proyectos tradicional
debido a los bucles de proceso más ajustados. Cada sprint aporta algo nuevo para que
el equipo debe aprender.

Por ejemplo:

Un equipo ofrece valor al cliente, recibe comentarios y, a continuación, modifica su

trabajo pendiente en función de ese comentario.
 Aprende que a las compilaciones automatizadas les faltan pruebas clave. Incluye
trabajo en próximo sprint para abordar la cuestión.
Descubre que determinadas características funcionan mal en producción, por lo
que diseña planes para mejorar el rendimiento.
Alguien del equipo se entera de una nueva práctica. El equipo decide probarla
durante algunos sprints.

Los equipos que apenas están comenzando con el desarrollo de Agile deben prever más
oportunidades de aprendizaje. Son una parte de gran valor del proceso porque
conducen al crecimiento y la mejora.

Pasos siguientes
Existen muchas formas de establecer un proceso de desarrollo de Agile adecuado para
un equipo. Azure DevOps ofrece varias plantillas de proceso. Los equipos que busquen
estructuras de referencia diferentes para su planeamiento pueden utilizar estas plantillas
como base de partida. Para obtener información sobre cómo seleccionar una plantilla
de proceso que mejor se adapte a la cultura y los objetivos de un equipo, consulte
Elección de un flujo de proceso o una plantilla de proceso para trabajar en Azure
Boards.

A medida que las organizaciones crecen, mantener la disciplina puede ser todo un reto.
Descubra cómo escalar Agile a equipos grandes.
¿Qué es Scrum?
Artículo • 05/10/2023

Scrum es un marco que utilizan los equipos para administrar el trabajo y resolver
problemas de forma colaborativa en ciclos cortos. Scrum pone en práctica los principios
de Agile como un conjunto concreto de artefactos, prácticas y roles.

El ciclo de vida de Scrum

En el diagrama a continuación se muestra el ciclo de vida iterativo de Scrum. La
totalidad del ciclo de vida se completa en períodos de tiempo fijos que se conocen
como sprints. Un sprint suele tener una duración de una a cuatro semanas.

Roles de equipo de Scrum

Existen tres roles esenciales en Scrum: el propietario del producto, el facilitador y el
equipo de desarrollo.

Propietario del producto

El propietario del producto es el responsable de lo que crea el equipo y de por qué lo
crea. El propietario del producto es el responsable de mantener el trabajo pendiente al
día y en orden de prioridad.

Facilitador
El facilitador garantiza que el equipo cumpla el proceso Scrum. Los facilitadores están
continuamente en busca de posibles mejoras para el equipo, al tiempo que resuelven
los impedimentos y otros problemas de bloqueo que puedan surgir durante el sprint.
Los facilitadores son en parte entrenadores, en parte miembros del equipo y en parte
animadores.

Equipo de desarrollo
Los miembros del equipo de desarrollo son quienes realmente crean el producto. El
equipo posee la ingeniería del producto y la calidad que lo acompaña.

Trabajo pendiente del producto

El trabajo pendiente del producto es una lista prioritaria del trabajo que el equipo puede
entregar. El propietario del producto es el responsable de añadir, cambiar y volver a
establecer prioridades en el trabajo pendiente según sea necesario. Los elementos de la
parte superior del trabajo pendiente deben estar siempre listos para que el equipo los
ejecute.

Planeamiento de sprint
En el planeamiento de sprint, el equipo elige los elementos de trabajo pendiente en los
que trabajarán en el próximo sprint. El equipo elige los elementos de trabajo pendiente
en función de su prioridad y lo que creen que pueden completar en el sprint. El trabajo
pendiente del sprint es la lista de elementos que el equipo planea entregar en el sprint. A
menudo, los elementos del trabajo pendiente del sprint se desglosan en tareas. Una vez
que todos los miembros hayan acordado que el trabajo pendiente del sprint es viable,
se inicia el sprint.

Ejecución del sprint

Una vez que se inicia el sprint, el equipo ejecuta el trabajo pendiente del sprint. Scrum
no especifica la forma en que el equipo debe llevar a cabo la ejecución. El equipo decide
la forma en que va a administrar su propio trabajo.

Scrum define una práctica conocida como Scrum diario, a menudo también llamada
reunión diaria. El Scrum diario es una reunión diaria que se limita a quince minutos. Los
miembros del equipo suelen quedarse de pie durante la reunión para asegurarse de que
sea breve. Cada miembro del equipo informa brevemente de los progresos desde el día
anterior, de los planes para la jornada de hoy y de cualquier obstáculo que impida su
avance.

Para ayudar al Scrum diario, los equipos suelen revisar dos artefactos:
Panel de tareas
El panel de tareas enumera cada elemento del trabajo pendiente en el que está
trabajando el equipo, y lo desglosa en las tareas necesarias para completarlo. Las tareas
se dividen en las columnas Pendiente, En curso y Finalizada en función del estado en
que se encuentren. El panel proporciona una manera visual de realizar un seguimiento
del progreso de cada elemento de trabajo pendiente.

Descubra más acerca de los paneles de tareas Kanban.

Gráfico de evolución de sprint

La evolución del sprint es un gráfico que traza el total diario del trabajo restante, que
habitualmente se muestra en horas. El diagrama de evolución ofrece una manera visual
de mostrar si el equipo va por buen camino para completar todo el trabajo al final del
sprint.

Revisión de sprint y retrospectiva de sprint

Al final del sprint, el equipo desempeña dos prácticas:

Revisión de sprint
El equipo muestra a las partes interesadas lo que se ha logrado. Demuestran el software
y su valor.
Retrospectiva de sprint
El equipo se toma el tiempo para reflexionar sobre lo que ha ido bien y lo que hay que
mejorar. El resultado de la retrospectiva son acciones para el siguiente sprint.

Increment
El producto de un sprint se conoce como incremento o incremento potencialmente apto
para el envío. Sin importar el término, el resultado de un sprint debe ser de calidad apta
para el envío, incluso si forma parte de algo más grande y no puede enviarse por sí solo.
Debe satisfacer todos los criterios de calidad definidos por el equipo y el propietario del
producto.

Repetir, aprender, mejorar

El ciclo completo se repite para el siguiente sprint. El planeamiento de sprint identifica
los siguientes elementos a incluir en el trabajo pendiente del producto y el ciclo se
repite. Mientras el equipo ejecuta el sprint, el propietario del producto garantiza que los
elementos de la parte superior del trabajo pendiente estén listos para ejecutarse en el
siguiente sprint.

Este ciclo iterativo más corto ofrece al equipo múltiples oportunidades de aprendizaje y
mejora. Un proyecto tradicional normalmente tiene un ciclo de vida largo, de 6 a 12
meses. Si bien un equipo puede aprender de un proyecto tradicional, las oportunidades
son mucho menores que las de un equipo que ejecuta en sprints de dos semanas, por
ejemplo.

Este ciclo iterativo es, en muchos sentidos, la esencia de Agile.

Scrum es muy popular porque ofrece el marco justo para guiar a los equipos, al tiempo
que les da flexibilidad en la ejecución. Sus conceptos son sencillos y fáciles de aprender.
Los equipos pueden empezar a trabajar rápidamente y aprender sobre la marcha. Todo
esto hace que Scrum sea una gran alternativa para los equipos que empiezan a
implementar los principios de Agile.

Pasos siguientes
Puede obtener más información sobre los recursos de Scrum, el entrenamiento y la
certificación en:

[Link]
 [Link]

Descubra cómo administrar el proceso Scrum.

Las organizaciones más grandes y complejas pueden considerar que Scrum no se ajusta
del todo a sus necesidades. Para esos casos, consulte Scaled Agile Framework.
¿Qué es Kanban?
Artículo • 05/10/2023

Kanban es un concepto japonés que significa cartel o valla publicitaria. Un ingeniero

industrial llamado Taiichi Ohno desarrolló Kanban en Toyota Motor Corporation para
mejorar la productividad.

Aunque Kanban se creó para la producción, el desarrollo de software comparte muchos

de los mismos objetivos, como aumentar el flujo y el rendimiento. Los equipos de
desarrollo de software pueden mejorar su productividad y ofrecer valor a los usuarios
con mayor rapidez gracias al uso de los principios y métodos de Kanban.

Principios de Kanban
La adopción de Kanban requiere la adopción de algunas prácticas fundamentales que
pueden ser distintas de los métodos que utilizaban anteriormente los equipos.

Visualización del trabajo

Comprender el estado del equipo de desarrollo y el progreso del trabajo pueden
constituir un reto. El progreso del trabajo y el estado actual son más fáciles de entender
cuando se presentan visualmente en lugar de en forma de lista de elementos de trabajo
o documento.

La visualización del trabajo es un principio esencial que Kanban aborda

fundamentalmente a través de los tableros Kanban. Estos tableros usan tarjetas
organizadas por progreso para comunicar el estado general. Visualizar el trabajo como
tarjetas en diferentes estados en un tablero ayuda a ver fácilmente el panorama general
de la situación actual de un proyecto, así como a identificar posibles cuellos de botella
que podrían afectar a la productividad.

Uso de un modelo de extracción

Históricamente, las partes implicadas solicitaban funcionalidades imponiendo el trabajo
a los equipos de desarrollo, a menudo con plazos muy ajustados. La calidad mermaba si
los equipos tenían que tomar atajos para entregar la funcionalidad en el plazo previsto.

Kanban se centra en mantener un nivel de calidad convenido que debe satisfacerse

antes de considerar el trabajo realizado. Para aplicar este modelo, las partes implicadas
no imponen trabajo a los equipos que ya están trabajando al máximo de su capacidad.
Por el contrario, añaden solicitudes a un registro de trabajo pendiente que un equipo
incorpora a su flujo de trabajo a medida que se dispone de capacidad.

Establecimiento de un límite de WIP

Los equipos que intentan trabajar en demasiadas cosas simultáneamente pueden
reducir su productividad debido a los frecuentes y costosos cambios de contexto. El
equipo está atareado, pero el trabajo no se realiza, lo que da lugar a plazos de entrega
inaceptablemente elevados. Limitar el número de elementos del trabajo pendiente en
los que un equipo puede trabajar a la vez permite aumentar la concentración y reducir
los cambios de contexto. Los temas en los que trabaja actualmente el equipo se
denominan trabajo en curso (WIP).

Los equipos deciden un límite de WIP o el número máximo de elementos en los que
pueden trabajar al mismo tiempo. Un equipo bien disciplinado se asegura de no superar
su límite de WIP. Si los equipos superan sus límites de WIP, estudian el motivo y
trabajan para solucionar la causa raíz.
Medición de la mejora continua
Para poner en práctica la mejora continua, los equipos de desarrollo necesitan una
forma de medir la eficacia y el rendimiento. Los tableros Kanban ofrecen una visión
dinámica de los estados del trabajo en un flujo de trabajo, por lo que los equipos
pueden ensayar procesos y evaluar más fácilmente el impacto en los flujos de trabajo.
Los equipos que adoptan Kanban para la mejora continua utilizan medidas como plazo
de entrega y tiempo de ciclo.

Paneles Kanban
El panel Kanban es una de las herramientas que usan los equipos para implementar
prácticas Kanban. Un panel Kanban puede ser un panel físico o una aplicación
informática que muestre las tarjetas dispuestas en columnas. Los nombres de columna
habituales son Pendiente, En curso y Finalizado, pero los equipos pueden personalizar
los nombres para que se adapten a sus estados de flujo de trabajo. Por ejemplo, es
posible que un equipo prefiera usar Nuevo, Desarrollo, Prueba, UAT y Finalizado.

Los paneles Kanban basados en el desarrollo de software muestran tarjetas que

coinciden con elementos del registro de trabajo pendiente del producto. Las tarjetas se
vinculan a otros elementos, como tareas y casos de prueba. Los equipos pueden
personalizar las tarjetas para incluir información importante para su proceso.

En un panel Kanban, el límite de WIP se aplica a todas las columnas de trabajo en curso.
Los límites de WIP no se aplican a las primeras y últimas columnas, ya que representan
el trabajo que no se ha iniciado o se ha completado. Los paneles Kanban ayudan a los
equipos a permanecer dentro de los límites de WIP al atraer la atención hacia las
columnas que superan los límites. Por consiguiente, los equipos pueden decidir un curso
de acción para eliminar el cuello de botella.
Diagramas de flujo acumulado
Una incorporación común a los paneles Kanban basados en el desarrollo de software es
un gráfico conocido como diagrama de flujo acumulado (CFD). El CFD representa el
número de elementos de cada estado a lo largo del tiempo, normalmente a través de
varias semanas. El eje horizontal indica la escala de tiempo y el eje vertical indica el
número de elementos de trabajo pendiente del producto. Las áreas que aparecen en
color indican los estados o columnas en las que están actualmente las tarjetas.

El CFD es muy útil para identificar tendencias a lo largo del tiempo, incluidos los cuellos
de botella y otras alteraciones de la velocidad de avance. Un buen CFD muestra una
tendencia ascendente coherente durante el trabajo de un equipo en un proyecto. Las
áreas que aparecen en color deben ser aproximadamente paralelas si el equipo está
trabajando dentro de sus límites de WIP.

Un saliente en una o varias de las áreas en color suele indicar un cuello de botella o un
obstáculo en el flujo del equipo. En el CFD a continuación, el trabajo completado en
verde es plano, mientras que el estado de prueba en azul está creciendo, posiblemente
a causa de un cuello de botella.
Kanban y Scrum en el desarrollo Agile
Aunque en líneas generales encajan en el ámbito del desarrollo Agile, Scrum y Kanban
son bastante diferentes.

Scrum se centra en sprints de duración fija, mientras que Kanban es un modelo de

flujo continuo.
Scrum posee roles definidos, mientras que Kanban no define ningún rol de equipo.
Scrum utiliza la velocidad como una métrica clave, mientras que Kanban utiliza el
tiempo de ciclo.

Los equipos suelen adoptar una combinación de aspectos de Scrum y Kanban para
trabajar de forma más eficaz. Independientemente de las características que elijan, los
equipos siempre pueden revisar y modificar hasta encontrar la más adecuada. Los
equipos deben empezar por lo sencillo y no perder de vista la importancia de aportar
valor regularmente a los usuarios.

Kanban con GitHub

GitHub ofrece una experiencia Kanban mediante paneles de proyecto (clásico) . Estos
paneles ayudan a organizar y priorizar el trabajo para el desarrollo de características
específicas, hojas de ruta globales o listas de verificación de versiones. Es posible
automatizar los paneles de proyecto (clásico) para sincronizar el estado de las tarjetas
con las incidencias y solicitudes de incorporación de cambios asociadas.
Kanban con Azure Boards
Azure Boards proporciona una solución Kanban completa para el planeamiento de
DevOps. Azure Boards se integra profundamente en Azure DevOps y también puede
formar parte de la integración Azure Boards-GitHub.

Para obtener más información, consulte Motivos para usar Azure Boards para
planear y realizar un seguimiento del trabajo.
El módulo de aprendizaje Elección de un enfoque Agile para el desarrollo de
software ofrece una experiencia práctica de Kanban en Azure Boards.
Adopción de una cultura ágil
Artículo • 05/10/2023

Si hay una enseñanza que ha dejado la última década de "transformaciones Agile", es

que no existe una solución única cuando hablamos de adoptar o implementar un
enfoque Agile. Cada organización tiene necesidades, restricciones y requisitos
diferentes. Seguir meramente instrucciones sin pensar no llevará al éxito.

El movimiento Agile se refiere a la búsqueda continua de formas de mejorar el enfoque

y la práctica de la creación de software. No se trata de un perfecto standup diario o de
una mirada retrospectiva. Se trata de crear una referencia cultural en la que se haga lo
correcto la mayoría de las veces. Las actividades como standups y miradas
retrospectivas son importantes, pero no cambiarán la cultura de una organización.

En este artículo se explican los elementos fundamentales que todas las organizaciones
necesitan para crear una mentalidad y una cultura Agile. Las recomendaciones no deben
seguirse sin más. Cada organización debe aplicar lo que resulte lógico en un contexto
determinado.

Programación y ritmo
No existe el sprint de duración perfecta. Hay equipos que han tenido éxito con sprints
que oscilan entre una y cuatro semanas. Lo más importante es la coherencia.

Seleccione una duración de etapa de trabajo que se adecue a la cultura, el producto y el

deseo de la organización para realizar actualizaciones. Por ejemplo, la división de
Herramientas de desarrollo de Microsoft (que integran aproximadamente 6000
personas) trabaja con sprints de tres semanas de duración. El equipo directivo no eligió
la duración del sprint, sino que es el resultado de los comentarios directos de los
equipos de ingeniería. Toda la división opera con la misma programación de sprints de
tres semanas. Los sprints se han convertido desde entonces en el latido de la
organización. Ahora todos los equipos marchan al ritmo del mismo tambor.

Es importante decidir la duración del sprint y respetarla. Si hay varios equipos de Agile,
la duración del sprint deberá ser la misma para todos. Si los comentarios impulsan un
cambio, entonces sea receptivo. Cuando el periodo que se aplique sea el adecuado, se
verá con claridad.

Una cultura de envío

Peter Provost , Administrador principal de programas del grupo Microsoft, dijo: "No se
puede engañar al transporte". La simplicidad y la verdad de esa declaración es una
piedra angular de la cultura Agile. Lo que quiere decir Peter con esto es que el envío del
software le enseñará cosas que de otra manera no comprenderá.

Está en la naturaleza humana retrasar o evitar hacer cosas hasta que sea absolutamente
necesario. Esto no puede ser más cierto cuando se trata del desarrollo de software. Los
equipos posponen tareas hasta el final, no piensan en la configuración o actualización
hasta que se ven obligados a hacerlo y habitualmente evitan cosas como la localización
y la accesibilidad siempre que sea posible. Cuando este patrón surge, los equipos crean
una deuda técnica que deberán pagar más adelante. El envío exige que se pague toda la
deuda. No se puede engañar al transporte. Para establecer una cultura Agile, comience
por intentar enviar el producto al final de cada sprint. No será fácil al principio, pero
cuando un equipo lo intenta, descubre rápidamente todas las cosas que deberían
suceder, pero no suceden.

Equipos saludables
No hay receta para el equipo de Agile perfecto. Sin embargo, algunas características
clave facilitan mucho el éxito.

Junte a los equipos siempre que sea posible

¿Puede ser exitoso un equipo con personas distribuidas en diferentes zonas
geográficas? Sí, pero es más difícil. Cuando la gente se encuentra en una misma
habitación, surgen las conversaciones correctas. Sin embargo, es posible tener éxito con
equipos ubicados en todo el mundo y en diferentes zonas horarias. ¿Pero no sería mejor
si ese equipo no tuviera todos esos obstáculos?
Mantenga los equipos intactos durante un período de
tiempo razonable
Permita a los equipos dominar el arte de crear software juntos. Cuando los equipos se
mezclan, cualquier química que hayan desarrollado entre sí se interrumpe. A veces es
adecuado reorganizar, pero los equipos suelen ser más productivos cuando se les da
tiempo para aprender a trabajar juntos. Como norma, intente mantener los equipos
intactos durante al menos 12 meses.

Equilibre la carga de trabajo, no las personas

En ocasiones, hay equipos que se retrasan y necesitan ayuda. Una forma habitual de
abordar esto es que un equipo preste a uno de sus miembros a otro equipo. Sin
embargo, puede resultar contraproducente. Una mejor solución es equilibrar la carga de
trabajo con otro equipo, en lugar de equilibrar la carga de las personas de los equipos.
Sacar a una persona de un equipo para ayudar a otro genera una interrupción en ambos
equipos y puede frustrar a la persona en cuestión, incluso si es temporal. Todo esto
afecta a la productividad del equipo y es muy posible que afecte negativamente a la
capacidad de volver a la programación establecida.

Equilibrar la carga de trabajo en lugar de las personas permite que un equipo que ya
está establecido pueda avanzar y ayudar. Se convierte en una cuestión de prioridades,
en lugar de una cuestión de las personas.

Permita que los equipos se apropien de las

áreas de características, no de las capas de la
arquitectura
Haga un esfuerzo por crear equipos verticales que se apropien de las áreas de
características. Estos equipos son responsables del trabajo necesario para añadir
características a su área, desde la base de datos hasta los cambios de la interfaz de
usuario. El equipo está capacitado para ofrecer y una experiencia integral.

Cuando los equipos horizontales se encargan de las capas de la arquitectura, ningún

equipo es responsable de la experiencia integral. La incorporación de una característica
requiere que varios equipos se coordinen y requiere un mayor nivel de gestión de
dependencias. La resolución de errores requiere que varios equipos investiguen si
poseen el código necesario para corregir el error. Los errores se producen al tiempo que
los equipos determinan que no es su error y lo asignan a otro equipo.
Los equipos de características no tienen estos problemas. La propiedad y la
responsabilidad están claras. Es posible que haya algunos equipos basados en la
arquitectura. Sin embargo, los equipos con enfoque vertical son más eficientes.

Pasos siguientes
A medida que los equipos inicien su propia transformación Agile, tenga en cuenta estos
principios fundamentales. Recuerde que no existe una receta única que funcione para
todas las organizaciones. Las transformaciones Agile son un proceso. Realice cambios y
aprenda de ellos. Con el tiempo, la organización desarrollará la cultura Agile necesaria.

Microsoft es una de las empresas Agile más grandes del mundo. Descubra más acerca
de cómo Microsoft adoptó una cultura Agile para el planeamiento de DevOps.

Descubra cómo Azure DevOps permite a los equipos adoptar y escalar una cultura Agile.
Creación de equipos productivos
Artículo • 05/10/2023

Los ingenieros prosperan en entornos en los que pueden concentrarse y entrar en la

zona. Los equipos suelen enfrentar distracciones y prioridades de competencia que
obligan a los ingenieros a cambiar el contexto y dividir la atención. Tienen dificultades
para equilibrar el tiempo de concentración con el tiempo de trabajo. La incorporación de
nuevas características requiere que los miembros del equipo se concentren. Responder
a los problemas de los clientes y solucionar problemas del sitio web en directo requiere
que el equipo esté atento a lo que ocurre.

Para atenuar las distracciones, un equipo puede dividirse en dos grupos: uno para
características y otro para el estado del sitio web en directo.

El enfoque de dos grupos produce una mayor productividad y previsibilidad. Una

implementación exitosa se basa en los siguientes elementos clave:

Roles de los grupos claramente definidos

Un proceso de rotación grupal bien definido
Ajustes frecuentes en el tamaño del grupo

Grupo de características
El grupo de características o grupo F se centra en el futuro. Trabajan como una unidad
eficaz con una misión clara y un objetivo: construir y enviar productos de alta calidad.

El grupo F está ajeno al caos diario del servicio en directo para asegurarse de tener el
tiempo para diseñar, construir y probar su trabajo. Tienen distracciones mínimas y no
tienen la obligación de corregir problemas que surjan al azar. Rara vez deben revisar la
casilla de correo electrónico y no se involucran en otros problemas a menos que estos
sean críticos.

Cuando un miembro del grupo F se une a una conversación o alguna vez queda
envuelto en un hilo de correo electrónico, otros miembros del equipo deben regañarlos:
"Eres del grupo F, ¿qué estás haciendo?" Si un miembro del grupo F debe resolver un
problema crítico, se recomienda que lo delegue al grupo del cliente y vuelva al trabajo
de características.

El grupo F funciona como un equipo muy unido que se concentra en un pequeño

conjunto de características. Un buen límite para un trabajo en curso (WIP) son dos
características para que ejecuten entre 4 a 6 personas. Al trabajar juntos de forma
estrecha, crean un contexto compartido profundo y encuentran errores críticos o
problemas de diseño que una revisión de código cursor pasaría por alto. Un grupo
especializado permite una velocidad de rendimiento y un tiempo de espera más
predecibles. Los miembros del equipo suelen referirse al grupo F como serenos y
centrados. Centrarse profundamente en una característica y dedicarle toda la atención
les resulta tranquilo y rejuvenecedor. La gente se va del grupo F sintiéndose renovada y
realizada.

Grupo del cliente

El grupo del cliente, o grupo C, se centra en el ahora y proporciona soporte técnico de
primera línea para los problemas del cliente y del sitio web directo, errores, telemetría y
supervisión. El grupo C a menudo se agrupa alrededor de un ordenador, mientras
resuelve un problema crítico en el sitio web directo. Su prioridad número uno es el
estado del sitio web directo. Centrados como láseres en este entorno, desarrollan
habilidades expertas de depuración y análisis. A menudo, al grupo del cliente se le
conoce como el equipo escudo, ya que protege al resto del equipo de las distracciones.
En lugar de trabajar con las características del futuro, el grupo C es el puente entre los
clientes y el producto actual. Los miembros del grupo están siempre activos en el correo
electrónico, Twitter y otros canales de comunicación. Los clientes quieren saber que se
les escucha; tal es el trabajo del grupo C. El grupo C resuelve de inmediato los
problemas comunicados por los clientes y se involucra y ayuda rápidamente a los
clientes bloqueados.

Con una avalancha de tareas entrantes, trabajar en un grupo C de ritmo rápido puede
ser, a veces, estimulante. En una semana ajetreada, atienden múltiples correos
electrónicos, investigaciones in situ y fallos. Cuando las operaciones se calman, trabajan
para mejorar la telemetría y los informes, e invierten su tiempo en facilitar el
mantenimiento de los servicios.

Los grupos C permiten al equipo abordar los problemas sin apartar a los miembros de
otras prioridades, y garantizan que se escuche a los clientes y socios. La capacidad de
respuesta a preguntas y problemas se convierte en un motivo de orgullo para los
grupos C. Sin embargo, este ritmo puede resultar agotador, lo que exige una rotación
frecuente entre los grupos.

Rotación de los grupos

Un proceso de rotación bien definido hace que el sistema de dos grupos funcione. Se
podría simplemente intercambiar los grupos (el grupo F se convierte en grupo C y
viceversa), pero esto limita el intercambio de conocimientos entre los grupos y al
interior de los mismos. En lugar de ello, opte por una rotación semanal.

Al final de cada semana, realice una breve reunión de intercambio donde el equipo
decida quién intercambia entre grupos. Puede utilizar un gráfico de pizarra para saber
quién forma parte de cada grupo y cuándo se intercambiaron. Por lo general, las
personas con más antigüedad en cada grupo deberían intercambiarse entre sí. Sin
embargo, en una semana determinada, puede que alguien quiera quedarse para
completar el trabajo de una investigación o característica del sitio web en directo.
Aunque haya flexibilidad, cuanto más tiempo esté alguien en un grupo, más probable
será que deba intercambiar.

Las rotaciones semanales ayudan a evitar la acumulación de conocimientos en el equipo

y garantizan un flujo constante de información y perspectivas entre los grupos. El
intercambio frecuente de ingenieros crea un conocimiento compartido del trabajo del
equipo, lo que ayuda al grupo C a resolver problemas sin la ayuda de otros. A menudo,
los nuevos miembros del grupo F encuentran rápidamente un diseño o un error de
código que se han pasado por alto anteriormente.

Tamaño del grupo

El tamaño del grupo varía para mantener la salud del equipo. Si un equipo tiene un alto
índice de entrada de problemas en directo o tiene mucha deuda técnica, el grupo C
aumenta, y viceversa. El ajuste semanal de los tamaños de los grupos aumenta la
previsibilidad en las entregas y dependencias del equipo. En algunas semanas, un
equipo puede trasladar a todo el mundo al grupo C para abordar los comentarios de un
gran lanzamiento.
Esta estrategia simplifica la comunicación con la administración. Sin un sistema de dos
grupos, los ingenieros suelen trabajar en varias cosas a la vez. Cuando se producen
varias distracciones en una misma semana, las características en curso tienden a
retrasarse. En consecuencia, un equipo puede ser incapaz de establecer plazos fiables
para el trabajo futuro.

Un grupo F especializado permite predecir el caudal y el plazo de entrega. Dividir los

recursos entre grupos aumenta la responsabilidad dentro del equipo y ante la
administración sobre lo que el equipo puede lograr cada semana y cada periodo de
trabajo.

Pasos siguientes
El sistema de dos grupos puede ayudar a los equipos a saber a qué deben dedicar su
tiempo los ingenieros y a avanzar en muchas prioridades que compiten entre sí.

Además de mejorar la productividad y la previsibilidad, el sistema de dos grupos puede

aumentar la moral del equipo. Los ingenieros de cada equipo comprenden claramente
sus funciones y responsabilidades y trabajan con mayor independencia y
responsabilidad. Este enfoque es ideal para los equipos de DevOps, que son
responsables tanto del desarrollo como de las operaciones. Sin embargo, este enfoque
se puede aplicar a casi cualquier equipo de Agile que trabaje con prioridades
competitivas.

Microsoft es una de las empresas Agile más grandes del mundo. Descubra cómo
Microsoft organiza los equipos en el planeamiento de DevOps.
Escalado de la cultura ágil a equipos
grandes
Artículo • 05/10/2023

Las palabras grande y Agile no suelen usarse en la misma frase. Las grandes
organizaciones se han ganado la fama de ser lentas. Sin embargo, la situación está
cambiando. Muchas grandes empresas de software están llevando a cabo con éxito la
implantación de Agile. Están aprendiendo a escalar los principios de Agile con o sin
marcos populares como SAFe, LeSS o Nexus .

En Microsoft, una organización utiliza Agile para crear productos y servicios que se
distribuyen bajo la marca Azure DevOps. Este grupo tiene 35 equipos de características
que pasan a producción cada tres semanas.

Todos los equipos de Azure DevOps son propietarios de las características desde su
creación hasta su finalización y más allá. Son dueños de las relaciones con los clientes.
Gestionan su propia cartera de productos. Escriben y comprueban el código en la rama
de producción. Cada tres semanas se despliega la rama de producción y la actualización
se hace pública. A continuación, los equipos supervisan el estado del sistema y
solucionan los problemas en directo.

Según los principios ágiles, los equipos autónomos son más productivos. Una
organización Agile quiere que sus equipos tengan control sobre su ejecución diaria.
Pero la autonomía sin alineación llevaría al caos. Docenas de equipos que trabajan de
forma independiente no producirían un producto unificado y de alta calidad. La
alineación otorga a los equipos su propósito y garantiza que cumplan los objetivos de la
organización. Sin alineación, incluso los equipos con mejor rendimiento fracasarían.

Para escalar Agile, hay que permitir la autonomía del equipo al tiempo que se
garantiza la alineación con la organización.

Para administrar el delicado equilibrio entre alineación y autonomía, los líderes de

DevOps necesitan definir una taxonomía, definir un proceso de planeamiento y utilizar
charlas de características.

Definición de una taxonomía

Un equipo de Agile, y la organización más grande de la que forma parte, requieren una
cartera de pedidos claramente definida para tener éxito. Los equipos tendrán
dificultades para tener éxito si los objetivos de la organización no están claros.
Para fijar objetivos claros y establecer cómo cada equipo puede colaborar en su
consecución, la organización debe definir una taxonomía. Una taxonomía claramente
establecida crea la nomenclatura de una organización.

Una taxonomía habitual es epopeyas, características, casos y tareas.

Epopeyas
Las epopeyas describen iniciativas importantes para el éxito de la organización. Las
epopeyas pueden llevar varios equipos y varios sprints, pero no carecen de fin. Las
epopeyas tienen un objetivo claramente definido. Una vez que se alcanza el objetivo, la
epopeya se cierra. El número de epopeyas en curso debe ser manejable para mantener
la organización centrada. Las epopeyas se dividen en características.

Características
Las características definen las nuevas funcionalidades necesarias para hacer realidad el
objetivo de una epopeya. Las características son la unidad de distribución; representan
lo que se entrega al cliente. Las notas de distribución pueden elaborarse a partir de la
lista de características que se han completado recientemente. Las características pueden
llevar varios sprints para completarse, pero deben dimensionarse para garantizar un
flujo constante de valor para el cliente. Las características se dividen en casos.

Casos
Los casos definen el valor añadido que el equipo debe aportar para crear una
característica. El equipo divide la característica en partes graduales. Es posible que un
único caso no aporte un valor significativo al cliente. Sin embargo, un caso representa
un software de calidad de producción. Los casos son la unidad de trabajo del equipo. El
equipo establece los casos necesarios para completar una característica. Los casos se
desglosan opcionalmente en tareas.

Tareas
Las tareas establecen el trabajo necesario para completar un caso.

Iniciativas
Esta taxonomía no es un sistema universal. Muchas organizaciones incorporan un nivel
superior a las epopeyas que llaman iniciativas.

Los nombres de cada nivel pueden adecuarse a las necesidades de la organización. Sin
embargo, los conceptos definidos anteriormente (epopeyas, características, casos) se
usan ampliamente en el sector.

Línea de autonomía
Una vez que se fija una taxonomía, la organización debe trazar una línea de autonomía.
La línea de autonomía es el punto en el que la propiedad del nivel se traslada de la
administración al equipo. La administración no interviene en los niveles que son
propiedad del equipo.

El ejemplo a continuación muestra la línea de autonomía trazada debajo de las

características. La administración es propietaria de las epopeyas y las características, lo
que genera alineación. Los equipos son propietarios de los casos y las tareas, y tienen
autonomía sobre cómo se ejecutan.

En este ejemplo, la administración no indica al equipo cómo dividir los casos, planear los
sprints o ejecutar el trabajo.

El equipo, sin embargo, debe garantizar que la ejecución se ajuste a los objetivos de la
administración. Aunque un equipo sea propietario de su cartera de historias, debe
alinearla con las características que se le hayan asignado.

Planificación
Para escalar el planeamiento de Agile, un equipo debe contar con un plan para cada
nivel de la taxonomía. Sin embargo, es importante repetir y actualizar el plan. Este
proceso se denomina planeamiento por oleadas.

El plan ofrece orientación durante un periodo fijo de tiempo con una estimación de
ajuste a intervalos regulares. Por ejemplo, un plan de 18 meses podría ajustarse cada
seis meses.

Este es un ejemplo de métodos de planeamiento para cada nivel de una taxonomía:

epopeyas, características, casos, tareas.
Visión
La visión se expresa a través de las epopeyas y establece la orientación de la
organización en el largo plazo. Las epopeyas establecen aquello que la organización
desea completar en los próximos 18 meses. La administración es propietaria del plan y
lo ajusta cada seis meses.

La visión se presenta en una reunión general. Como la visión pretende ser ambiciosa y
muchas cosas pueden cambiar en ese lapso de tiempo, se espera conseguir alrededor
del 60 % de la misma.

Temporada
Una temporada se describe a través de las características y establece la estrategia para
los próximos seis meses. Las características definen lo que la organización quiere
transmitir a sus clientes. La administración es propietaria del plan estacional y presenta
la visión y los planes estacionales en una reunión general. Todos los planes del equipo
deben alinearse con el plan estacional de la administración. Prevea cumplir en torno al
80 % del plan estacional.

Plan de 3 sprints
El plan de 3 sprints establece los casos y características que el equipo completará en los
próximos tres sprints. El equipo es propietario del plan y lo ajusta en cada sprint. Cada
equipo presenta su plan a la administración a través de la charla de características
(consulte a continuación). El plan detalla cómo se alinea la ejecución del equipo con el
plan estacional de 6 meses. Prevea lograr en torno al 90 % del plan de 3 sprints.

Plan de sprint
El plan de sprint establece los casos y características que completará el equipo en el
siguiente sprint. El equipo es propietario del plan de sprint y lo envía por correo
electrónico a toda la organización para lograr una transparencia completa. El plan
incluye lo que el equipo ha logrado en el sprint anterior y su enfoque para el siguiente.
Prevea lograr en torno al 95 % del plan de sprint.

Línea de autonomía
En este ejemplo, la línea de autonomía se traza para mostrar el punto en el que los
equipos tienen autonomía en el planeamiento.

Como se indicó antes, la propiedad de la administración no se extiende más allá de la

línea de autonomía. La administración ofrece orientación a través de la visión y los
planes de temporada y luego da autonomía a los equipos para crear planes de 1 y
3 sprints.

Charlas de características: donde la autonomía

se une a la alineación
Una charla de características es una reunión informal en la que cada equipo presenta su
plan de 3 sprints a la administración. Esta reunión garantiza que los planes del equipo se
alineen con los objetivos de la organización. También ayuda a la administración a
mantenerse al corriente de las actividades del equipo. Aunque el plan de 3 sprints se
ajusta en cada sprint, las charlas de características se realizan según sea necesario,
normalmente cada uno o tres sprints.
En una charla de características se conceden 15 minutos a cada equipo. Con 12 equipos,
estas reuniones pueden durar unas tres horas. Cada equipo prepara una presentación
de 3 diapositivas, que incluyen lo siguiente:

Características
La primera diapositiva esboza las características que el equipo abordará en los próximos
tres sprints.

Deuda
La siguiente diapositiva explica cómo gestiona el equipo la deuda técnica. Deuda se
refiere a todo aquello que no cumpla los criterios de calidad de la administración. El
director de ingeniería fija los criterios de calidad, que son los mismos para todos los
equipos (alineación). Algunos ejemplos de criterios de calidad son el número de errores
por ingeniero, el porcentaje de pruebas unitarias superadas y los objetivos de
rendimiento.

Problemas y dependencias
Los problemas y dependencias que se recogen en la última diapositiva incluyen
cualquier factor que afecte al progreso del equipo, como problemas que el equipo no
pueda resolver o dependencias de otros equipos que deban escalarse.

Cada equipo presenta las diapositivas directamente a la administración. El equipo

presenta de qué manera su plan de 3 sprints se alinea con el plan estacional de 6 meses.
La dirección formula preguntas aclaratorias y sugiere cambios de rumbo. Asimismo,
puede solicitar reuniones de seguimiento para resolver problemas más profundos.

Si el plan de un equipo no se alinea con las expectativas de la administración, esta

podrá solicitar un nuevo plan. En este caso poco frecuente, el equipo volverá a planear y
programará una nueva charla de características para revisarla.

Confianza: el pegamento que una alineación y

autonomía
Cuando se practica Agile a gran escala, la confianza es bidireccional:

La administración debe confiar en que los equipos harán lo correcto. Si la

administración no confía en los equipos, no les concederá autonomía.
 Un equipo se gana la confianza al entregar sistemáticamente códigos de alta
calidad. Si los equipos no son de confianza, la administración no les concederá
autonomía.

La administración debe ofrecer planes claros para que los equipos se alineen con ellos y
luego confiar en que sus equipos los ejecuten. Los equipos deben alinear sus planes con
la organización y llevarlos a cabo de forma confiable.

A medida que las organizaciones buscan escalar Agile a escenarios más grandes, la clave
es dar autonomía a los equipos al tiempo que se garantiza que se alineen con los
objetivos de la organización. Los pilares fundamentales son la propiedad claramente
definida y la cultura de confianza. Una vez que una organización disponga de esta base,
descubrirá que Agile puede escalar muy bien.

Pasos siguientes
Existen muchas formas de que un equipo de cualquier tamaño empiece a obtener
beneficios hoy mismo. Eche un vistazo a algunas de estas prácticas que se escalan.

Descubra las características de Azure DevOps para la administración de carteras y la

visibilidad entre equipos.

Microsoft es una de las empresas Agile más grandes del mundo. Descubra cómo
Microsoft escala el planeamiento de DevOps.
Cómo planea Microsoft con DevOps
Artículo • 05/10/2023

Microsoft es una de las empresas más grandes del mundo en utilizar metodologías
Agile. A lo largo de muchos años de experiencia, Microsoft ha desarrollado un proceso
de planeamiento de DevOps que abarca desde los proyectos más pequeños hasta
iniciativas masivas como Windows. En este artículo se describen muchas de las lecciones
aprendidas y las prácticas que Microsoft aplica a la hora de planear proyectos de
software en toda la empresa.

Cambios en los instrumentos

Los siguientes cambios clave ayudan a que los ciclos de desarrollo y envío sean más
saludables y eficientes:

Promover la alineación cultural y la autonomía.

Cambiar el enfoque de los individuos a los equipos.
Crear nuevas estrategias de planeamiento y aprendizaje.
Implantar un modelo de múltiples grupos.
Mejorar las prácticas de salud del código.
Fomentar la transparencia y la responsabilidad.

Promover la alineación cultural y la autonomía

Peter Drucker dijo: "La cultura se come a la estrategia para desayunar". La autonomía, el
dominio y el propósito son motivaciones humanas clave. Microsoft intenta proporcionar
estos motivadores a los PM, desarrolladores y diseñadores para que se sientan
capacitados para crear productos de éxito.

Dos colaboradores importantes para este enfoque son la alineación y la autonomía.

La alineación se produce de arriba abajo, para garantizar que las personas y los
equipos comprendan cómo se alinean sus responsabilidades con los objetivos
empresariales más amplios.
La autonomía se produce de abajo arriba, para garantizar que las personas y los
equipos influyan en las actividades y decisiones cotidianas.

Existe un delicado equilibrio entre alineación y autonomía. Demasiada alineación puede

crear una referencia cultural negativa en la que las personas solo funcionan como se les
dice. Demasiada autonomía puede provocar una falta de estructura o dirección, una
toma de decisiones ineficaz y un planeamiento deficiente.
Cambiar el enfoque de los individuos a los equipos
Microsoft organiza a las personas y los equipos en tres grupos: PM, diseño e ingeniería.

PM define qué construye Microsoft y por qué.

Diseño se encarga de diseñar lo que construye Microsoft.
Ingeniería construye los productos y garantiza la calidad de los mismos.

Los equipos de Microsoft tienen las siguientes características clave:

Interdisciplinarios
10-12 personas
Autogestión
Carta y objetivos claros para 12-18 meses
Salas físicas para equipos
Implementación de características propias
Características propias en la producción

Esfuerzo por crear equipos verticales

Los equipos de Microsoft solían ser horizontales y abarcaban toda la interfaz de usuario,
todos los datos o todas las API. Actualmente, Microsoft se esfuerza por crear equipos
verticales. Los equipos son dueños de sus áreas del producto de principio a fin. Las
estrictas directrices en determinados niveles garantizan la uniformidad entre los equipos
de todo el producto.

El diagrama a continuación conceptualiza la diferencia entre equipos horizontales y

verticales:

Permitir la autoselección de equipos

Aproximadamente cada 18 meses, Microsoft lleva a cabo un "ejercicio de pegatina
amarilla", en el que los desarrolladores pueden elegir en qué áreas del producto quieren
trabajar durante los próximos dos periodos de planeamiento. Este ejercicio proporciona
autonomía, ya que los equipos pueden elegir en qué trabajar, y alineación organizativa,
ya que fomenta el equilibrio entre los equipos. Aproximadamente el 80 % de las
personas que participan en este ejercicio permanecen en sus equipos actuales, pero se
sienten empoderadas porque han podido elegir.

Crear nuevas estrategias de planeamiento y aprendizaje

Dwight Eisenhower dijo: "Los planes no valen nada, pero el planeamiento lo es todo". El
planeamiento de Microsoft se divide en la siguiente estructura:

Sprints (3 semanas)
Planes (3 sprints)
Temporadas (6 meses)
Estrategias (12 meses)

Los ingenieros y los equipos son los principales responsables de los periodos de trabajo
y los planes. El liderazgo es el principal responsable de las temporadas y las estrategias.

El diagrama a continuación ilustra la estrategia de planeamiento de Microsoft:

La estructura de planeamiento también ayuda a maximizar el aprendizaje al mismo

tiempo que se planea. Los equipos reciben información, averiguan lo que quieren los
clientes y ponen en práctica sus pedidos con rapidez y eficacia.

Implantar un modelo de múltiples grupos

Los métodos anteriores fomentaban una "cultura de la interrupción" de los fallos y las
incidencias del sitio web en directo. Los equipos de Microsoft idearon su propia forma
de concentrarse y evitar distracciones. Los equipos se autoorganizan para cada etapa de
trabajo en dos grupos diferenciados: Características (grupo F) y Cliente (grupo C).

El grupo F trabaja en las características previstas y el grupo C se ocupa de los problemas

e interrupciones del sitio web en directo. El equipo establece una periodicidad de
rotación que permite a los miembros planear las actividades con mayor facilidad. Para
obtener más información sobre el modelo de múltiples grupos, consulte el apartado
Creación de equipos productivos y centrados en el cliente.

Mejorar las prácticas de salud del código

Antes de adoptar metodologías Agile, los equipos solían dejar que los errores se
acumularan hasta que el código estaba completo al final de la fase de desarrollo. A
continuación, los equipos descubrían fallos y trabajaban para solucionarlos. Esta práctica
creaba una montaña rusa de fallos que afectaba a la moral y la productividad de los
equipos, que tenían que trabajar en la corrección de errores en lugar de implementar
nuevas características.

En la actualidad, los equipos aplican un límite de errores que se calcula mediante la

fórmula # of engineers x 5 = bug cap . Si el recuento de errores de un equipo supera el
límite de al final de un sprint, deben dejar de trabajar en nuevas características y corregir
errores hasta que estén por debajo del límite. Los equipos ahora pagan la deuda de
errores a medida que avanzan.

Fomentar la transparencia y la responsabilidad

Al final de cada sprint, cada equipo envía un correo que informa lo que se ha logrado en
el sprint anterior y lo que planea hacer en el siguiente.

Objetivos y resultados clave (OKR)

Los equipos son más eficaces cuando tienen claros los objetivos que la organización
pretende alcanzar. Microsoft proporciona claridad a los equipos a través de objetivos y
resultados clave (OKR).

Objetivos definen los objetivos que se pretende alcanzar. Los objetivos son
declaraciones de intenciones significativas, concretas, orientadas a la acción e,
idealmente, inspiradoras. Los objetivos representan grandes ideas, no cifras
concretas.
 Los Resultados clave definen los pasos para alcanzar los objetivos. Los resultados
clave son resultados cuantificables que evalúan el progreso e indican el éxito
respecto a los objetivos en un periodo de tiempo específico.

Los OKR reflejan los mejores resultados posibles, no solo los más probables. Los líderes
tratan de ser ambiciosos y no precavidos. Impulsar a los equipos a perseguir resultados
clave estimulantes fomenta la aceleración con respecto a los objetivos y prioriza el
trabajo que avanza hacia metas más amplias.

Adoptar un marco de OKR puede ayudar a los equipos a rendir mejor por los siguientes
motivos:

Cada equipo está alineado en el plan.

Los equipos se centran en lograr resultados en lugar de realizar actividades.
Cada equipo es responsable de realizar esfuerzos de forma periódica.

Los OKR pueden existir en los distintos niveles de un producto. Por ejemplo, puede
haber OKR de producto a nivel superior, OKR a nivel de componentes y OKR a nivel de
equipo. Mantener los OKR alineados es relativamente fácil, especialmente si los
objetivos se establecen de arriba abajo. Cualquier conflicto que surja es un valioso
indicador precoz de desajuste organizativo.

Ejemplo de OKR
Objetivo: conseguir una base de clientes sólida y satisfecha.

Resultados clave:

Aumentar la puntuación del promotor neto (NPS) externo de 21 a 35.

Aumentar la satisfacción de los documentos de 55 a 65.
El nuevo flujo de distribución tiene una puntuación de Apdex de 0,9.
El tiempo de espera de los trabajos es de 5 segundos o menos.

Para obtener más información acerca de los OKR, consulte el apartado Medir los
resultados empresariales mediante objetivos y resultados clave.

Seleccionar las métricas adecuadas

Los resultados clave son tan útiles como las métricas en las que se basan. Microsoft usa
indicadores avanzados que se centran en el cambio. Con el tiempo, estas métricas
construyen una imagen operativa de la aceleración o desaceleración del producto.
Microsoft suele utilizar las siguientes métricas:
 Variación de la tasa de crecimiento mensual de la adopción
Cambio en el rendimiento
Cambio en el tiempo de aprendizaje
Cambio en la frecuencia de incidentes

Los equipos evitan las métricas que no aportan valor a los objetivos. Aunque puedan
tener ciertos usos, las siguientes métricas no son útiles para seguir el progreso hacia los
objetivos:

Estimaciones originales precisas

Horas completadas
Líneas de código
Capacidad del equipo
Evolución del equipo
Progreso del equipo
Número de errores detectados
Cobertura de código

Antes y después de la implantación de la

cultura Agile
La tabla a continuación resume los cambios que realizaron los equipos de desarrollo de
Microsoft al adoptar las prácticas Agile.

Antes del Después

Hitos de 4 a 6 meses Sprints de 3 semanas

Equipos horizontales Equipos verticales

Despachos personales Salas para equipos y trabajo a distancia

Ciclos de planeamiento largos Planeamiento y aprendizaje continuos

PM, desarrollo y pruebas PM, diseño e ingeniería

Compromiso anual con los clientes Compromiso continuo con los clientes

Ramas de características Todo el mundo trabaja en la sede central

Equipos de más de 20 personas Equipos de 8 a 12 personas

Plan de trabajo secreto Plan de trabajo compartido públicamente

Deuda de errores Deuda cero

Antes del Después

Documentos de 100 páginas Especificaciones de PowerPoint

Los repositorios privados Código abierto/código interno

Jerarquía organizativa profunda Jerarquía organizativa plana

Las cifras de instalación marcan el éxito La satisfacción de los usuarios marca el éxito

Envío de características una vez al año Envío de características en cada sprint

Puntos clave
Tómese en serio la ciencia Agile, pero no sea excesivamente prescriptivo. Agile
puede llegar a ser demasiado estricto. Deje que crezcan la mentalidad y la cultura
Agile.
Celebre los resultados, no la actividad. La implantación de la funcionalidad pesa
más que las líneas de código.
Realice envíos en cada sprint para establecer un ritmo y una cadencia y encontrar
todo el trabajo que haya que hacer.
Construya la cultura que desea para obtener el comportamiento que busca.
Desarrollo de software moderno con
DevOps
Artículo • 05/10/2023

La fase de desarrollo de DevOps es donde se produce todo el trabajo de desarrollo de

software principal. Como entrada, toma planes para la iteración actual, normalmente en
forma de asignaciones de tareas. A continuación, genera artefactos de software que
expresan la funcionalidad actualizada. El desarrollo no solo requiere las herramientas
que se usan para escribir código, como Visual Studio, sino que también admite servicios
como control de versiones, administración de problemas y pruebas automatizadas.

Seleccionar un entorno de desarrollo

Idealmente, los desarrolladores pasan la mayor parte de su tiempo en tareas de
desarrollo principales, como la edición y depuración de código. Tener la cadena de
herramientas adecuada puede marcar la diferencia entre la máxima productividad y el
rendimiento poco óptimo. Los entornos de desarrollo integrados (IDE) han
evolucionado más allá de sus humildes comienzos como lugares para editar y compilar
código. En la actualidad, los desarrolladores tienen la capacidad de realizar casi todas
sus tareas de DevOps desde una única experiencia de usuario cuando seleccionan el
entorno de desarrollo adecuado.
Administración del código a través del control
de versiones y Git
A medida que los equipos escalan, el número de partes interesadas que dependen de
los códigos base y contribuyen a ellos puede crecer rápidamente. Sin una estrategia
para administrar los cambios en el código fuente, los equipos de desarrollo se ponen en
riesgo considerable de confusión continua, errores y pérdida de productividad. La
implementación incluso del control de versiones más básico puede proteger contra esos
problemas. La mayoría de los equipos optan por usar Git, el sistema de control de
versiones más popular, para administrar su código.

Automatizar procesos
El valor real de la fase de desarrollo procede de la implementación de características.
Desafortunadamente, hay muchas otras tareas que roban tiempo al equipo de
desarrollo. La compilación de código, la ejecución de pruebas y la preparación de la
salida para la implementación son algunos ejemplos. Para minimizar el impacto, DevOps
enfatiza la automatización de estos tipos de tareas a través de la práctica de la
integración continua.

Otra tarea que consume mucho tiempo en el ciclo de vida de desarrollo es la corrección
de errores. Aunque los errores a menudo se ven como una parte inevitable del
desarrollo de software, hay pasos valiosos que cualquier equipo puede realizar para
reducirlos. Aprenda a desplazar a la izquierda para que las pruebas sean más rápidas y
fiables.

Pasos siguientes
Microsoft ha sido una de las empresas de desarrollo de software más grandes del
mundo durante décadas. Descubra cómo Microsoft desarrolla en DevOps.

Para obtener una experiencia práctica de DevOps con integración continua, consulte las
siguientes rutas de aprendizaje:

Administración del control de código fuente con GitHub

Definición e implementación de la integración continua con Azure DevOps
Administrar el ciclo de vida de los proyectos en GitHub
Seleccionar un entorno de desarrollo
Artículo • 05/10/2023

Seleccione el entorno de desarrollo adecuado para admitir la adopción y el rendimiento

de DevOps. Un entorno de desarrollo de DevOps no solo debe editar y depurar código,
sino integrarse con el resto del ciclo de DevOps, incluidas las pruebas, el control de
versiones y la supervisión de producción. Microsoft proporciona dos entornos de
desarrollo principales para admitir DevOps, Visual Studio y Visual Studio Code.

Usar Visual Studio

Visual Studio es un entorno de desarrollo integrado (IDE) con todas las características.
Si puede usarlo, Visual Studio es ideal para trabajar en Windows y compilar software
para varias plataformas, como .NET o .NET Core, iOS, Android a través de Xamarin y
destinos que admiten C++.

Visual Studio ofrece históricamente ventajas de integración y productividad de DevOps.

Visual Studio se integra de forma nativa con GitHub y Azure DevOps y tiene un sólido
ecosistema de extensiones para cada proveedor de DevOps del sector.

Usar Visual Studio Code

Visual Studio Code es un editor de código gratuito y optimizado que ofrece
personalización ilimitada a través de decenas de miles de extensiones comerciales y
comunitarias . Estas extensiones, además, son compatibles con prácticamente
cualquier lenguaje, plataforma y servicio DevOps. Los desarrolladores pueden ser
productivos en Windows, Mac o Linux. Visual Studio Code es la opción ideal para los
desarrolladores que no pueden usar Visual Studio.

Desarrollar para Azure

No hay ningún entorno de desarrollo preferido en concreto para las soluciones de
Azure. Gracias a la amplia compatibilidad con todas las plataformas de aplicaciones
principales, puede usar prácticamente cualquier herramienta para compilar soluciones
de Azure y seleccionar el modelo de implementación que mejor le convenga. La mejor
manera de implementar soluciones en producción suele ser mediante la automatización
hospedada en Acciones de GitHub o Azure Pipelines .
Tanto Visual Studio como Visual Studio Code tienen características nativas y extensiones
propias que simplifican el trabajo con procesos de DevOps en Azure, GitHub y Azure
DevOps.

Pasos siguientes
Aprenda a preparar Visual Studio, Visual Studio Code, Eclipse para Java e IntelliJ IDEA
para el desarrollo de Azure en el módulo de aprendizaje práctico Preparación del
entorno de desarrollo para el desarrollo de Azure.
¿Qué es el control de versiones?
Artículo • 05/10/2023

Los sistemas de control de versiones son un tipo de software que ayuda a hacer un
seguimiento de los cambios realizados en el código a lo largo del tiempo. A medida que
un desarrollador edita el código, el sistema de control de versiones toma una
instantánea de los archivos. Después, guarda esa instantánea de forma permanente para
que se pueda recuperar más adelante si es necesario.

Sin el control de versiones, los desarrolladores se sienten tentados a mantener varias

copias del código en su equipo. Esto es peligroso, ya que es fácil cambiar o eliminar un
archivo en la copia incorrecta del código, lo que podría hacer que perdieran el trabajo.
Los sistemas de control de versiones solucionan este problema al administrar todas las
versiones del código, pero presentan al equipo una sola versión a la vez.

¿Por qué importa el control de versiones?

Hay muchas tareas que suponen una gran inversión de tiempo para los desarrolladores.
La reproducción de errores, el aprendizaje de nuevas herramientas y la adición de
nuevas características o contenido son solo algunos ejemplos. A medida que las
demandas de los usuarios aumentan, el control de versiones ayuda a los equipos a
trabajar juntos y distribuir soluciones a tiempo.

Ventajas del control de versiones

El control de versiones beneficia muchos aspectos de la producción.

Crear flujos de trabajo

Los flujos de trabajo del control de versiones evitan el caos a todos los usuarios que
usan su propio proceso de desarrollo con herramientas diferentes e incompatibles. Los
sistemas de control de versiones proporcionan permisos y cumplimiento de procesos,
por lo que todos permanecen en sintonía.
Trabajo con versiones

Cada versión tiene una descripción de lo que hacen los cambios en la versión, como
corregir un error o agregar una característica. Estas descripciones ayudan al equipo a
seguir los cambios del código por versión en lugar de por cambios de archivo
individuales. El código almacenado en versiones se puede ver y restaurar desde el
control de versiones en cualquier momento y según sea necesario. Las versiones
facilitan basar el nuevo trabajo en cualquier versión del código.

Codificar juntos

El control de versiones sincroniza las versiones y garantiza que los cambios no entren en
conflicto con los cambios de otros usuarios. El equipo se basa en el control de versiones
para ayudar a resolver y evitar conflictos, incluso cuando los usuarios realizan cambios al
mismo tiempo.

Mantener un historial

El control de versiones mantiene un historial de los cambios a medida que el equipo

guarda nuevas versiones del código. Los miembros del equipo pueden revisar el
historial para averiguar la persona que realizó los cambios, por qué los hizo y en qué
momento. El historial ofrece a los equipos la confianza de experimentar, ya que es fácil
revertir a una versión anterior correcta en cualquier momento. El historial permite que
cualquier persona base el trabajo en cualquier versión del código, como corregir un
error en una versión anterior.

Automatización de tareas

Las características de automatización del control de versiones ahorran tiempo y generan

resultados coherentes. La automatización de pruebas, el análisis de código y la
implementación cuando se guardan nuevas versiones en el control de versiones son
solo tres ejemplos.

Pasos siguientes
Obtenga más información sobre el estándar mundial en el control de versiones, Git.
¿Qué es Git?
Artículo • 05/10/2023

Git se ha convertido en el estándar mundial para el control de versiones. ¿Y qué es

exactamente?

Git es un sistema de control de versiones distribuido, lo que significa que un clon local
del proyecto es un repositorio de control de versiones completo. Estos repositorios
locales plenamente funcionales permiten trabajar sin conexión o de forma remota con
facilidad. Los desarrolladores confirman su trabajo localmente y, a continuación,
sincronizan la copia del repositorio con la del servidor. Este paradigma es distinto del
control de versiones centralizado, donde los clientes deben sincronizar el código con un
servidor antes de crear nuevas versiones.

La flexibilidad y popularidad de Git lo convierten en una excelente opción para cualquier

equipo. Muchos desarrolladores y graduados universitarios ya saben cómo usar Git. La
comunidad de usuarios de Git ha creado recursos para entrenar a los desarrolladores y
la popularidad de Git facilita recibir ayuda cuando se necesita. Casi todos los entornos
de desarrollo tienen compatibilidad con Git y las herramientas de línea de comandos de
Git implementadas en todos los sistemas operativos principales.

Aspectos básicos de Git

Cada vez que se guarda el trabajo, Git crea una confirmación. Una confirmación es una
instantánea de todos los archivos en un momento dado. Si un archivo no ha cambiado
de una confirmación a la siguiente, Git usa el archivo almacenado anteriormente. Este
diseño difiere de otros sistemas que almacenan una versión inicial de un archivo y
mantienen un registro de las diferencias a lo largo del tiempo.

Las confirmaciones crean vínculos a otras confirmaciones, formando un gráfico del

historial de desarrollo. Es posible revertir el código a una confirmación anterior,
inspeccionar cómo cambian los archivos de una confirmación a la siguiente y revisar
información como dónde y cuándo se realizaron los cambios. Las confirmaciones se
identifican en Git mediante un hash criptográfico único del contenido de la
confirmación. Dado que todo tiene hash, es imposible realizar cambios, perder la
información o dañar los archivos sin que Git lo detecte.

Ramas
Cada desarrollador guarda los cambios en su propio repositorio de código local. Como
resultado, puede haber muchos cambios diferentes basados en la misma confirmación.
Git proporciona herramientas para aislar los cambios y volver a combinarlos
posteriormente. Las ramas, que son punteros ligeros para el trabajo en curso,
administran esta separación. Una vez finalizado el trabajo creado en una rama, se puede
combinar de nuevo en la rama principal (o troncal) del equipo.

Archivos y confirmaciones
Los archivos de Git se encuentran en uno de estos tres estados: modificados,
almacenados provisionalmente o confirmados. Cuando se modifica un archivo por
primera vez, los cambios solo existen en el directorio de trabajo. Todavía no forman
parte de una confirmación ni del historial de desarrollo. El desarrollador debe almacenar
provisionalmente los archivos modificados que se incluirán en la confirmación. El área de
almacenamiento provisional contiene todos los cambios que se incluirán en la siguiente
confirmación. Una vez que el desarrollador esté satisfecho con los archivos almacenados
provisionalmente, los archivos se empaquetan como una confirmación con un mensaje
que describe lo que ha cambiado. Esta confirmación pasa a formar parte del historial de
desarrollo.
El almacenamiento provisional permite a los desarrolladores elegir qué cambios de
archivo se guardarán en una confirmación para desglosar los cambios grandes en una
serie de confirmaciones más pequeñas. Al reducir el ámbito de las confirmaciones, es
más fácil revisar el historial de confirmaciones para buscar cambios de archivo
específicos.

Ventajas de Git
Las ventajas de Git son numerosas.

Desarrollo simultáneo
Todos los usuarios tienen su propia copia local de código y pueden trabajar
simultáneamente en sus propias ramas. Git funciona sin conexión, ya que casi todas las
operaciones son locales.

Versiones de lanzamiento más rápidas

Las ramas permiten un desarrollo flexible y simultáneo. La rama principal contiene
código estable y de alta calidad desde el que publica. Las ramas de características
contienen trabajo en curso y se combinan con la rama principal tras la finalización. Al
separar la rama de versión del desarrollo en curso, es más fácil administrar código
estable y enviar actualizaciones más rápidamente.

Integración incorporada
Debido a su popularidad, Git se integra en la mayoría de las herramientas y productos.
Todos los IDE principales tienen compatibilidad integrada con Git y muchas
herramientas admiten la integración y la implementación continuas, las pruebas
automatizadas, el seguimiento de los elementos de trabajo, las métricas y la integración
de características de informes con Git. Esta integración simplifica el flujo de trabajo
diario.
Sólido soporte técnico de la comunidad
Git es de código abierto y se ha convertido en el estándar de facto para el control de
versiones. No hay escasez de herramientas y recursos disponibles para que los equipos
aprovechen. El volumen de soporte técnico de la comunidad para Git en comparación
con otros sistemas de control de versiones facilita recibir ayuda cuando se necesita.

Git funciona con cualquier equipo

Utilizar Git con una herramienta de administración de código fuente aumenta la
productividad de un equipo al fomentar la colaboración, aplicar directivas, automatizar
procesos y mejorar la visibilidad y la rastreabilidad del trabajo. El equipo puede
decidirse por herramientas individuales para el control de versiones, el seguimiento de
los elementos de trabajo y la integración e implementación continuas. O bien, pueden
elegir una solución como GitHub o Azure DevOps que admita todas estas tareas en
un solo lugar.

Solicitudes de incorporación de cambios

Use solicitudes de incorporación de cambios para analizar los cambios de código con el
equipo antes de combinarlos con la rama principal. Las discusiones en las solicitudes de
incorporación de cambios son valiosas para garantizar la calidad del código y aumentar
los conocimientos en todo el equipo. Las plataformas como GitHub y Azure DevOps
ofrecen una experiencia de solicitud de incorporación de cambios enriquecida en la que
los desarrolladores pueden examinar los cambios de archivos, dejar comentarios,
inspeccionar confirmaciones, ver compilaciones y votar para aprobar el código.

Directivas de rama
Los equipos pueden configurar GitHub y Azure DevOps para aplicar flujos de trabajo y
procesos coherentes en todo el equipo. Pueden configurar directivas de rama para
asegurarse de que las solicitudes de incorporación de cambios cumplan los requisitos
antes de la finalización. Las directivas de rama protegen las ramas importantes al
prevenir las inserciones directas, requerir revisores y garantizar compilaciones limpias.

Pasos siguientes
Instalación y configuración de Git
Instalación y configuración de Git
Artículo • 05/10/2023

Git aún no es una opción predeterminada en los equipos, por lo que debe instalarse y
configurarse manualmente. Y, al igual que cualquier otro software, es importante
mantenerlo actualizado. Las actualizaciones protegen frente a vulnerabilidades de
seguridad, corrigen errores y proporcionan acceso a nuevas características.

En las secciones siguientes se describe cómo instalar y mantener Git en las tres
plataformas principales.

Instalación de Git para Windows

Descargue e instale Git para Windows . Una vez instalado, Git está disponible desde el
símbolo del sistema o PowerShell. Se recomienda seleccionar los valores
predeterminados durante la instalación, a menos que haya una buena razón para
cambiarlos.

Git para Windows no se actualiza automáticamente. Para actualizar Git para Windows,
descargue la nueva versión del instalador, que actualiza Git para Windows en su lugar y
conserva toda la configuración.

Instalar Git para macOS

macOS 10.9 (Mavericks) y versiones posteriores instala Git la primera vez que intenta
ejecutarlo desde el terminal. Aunque este método es una manera fácil de obtener Git en
un sistema, no permite el control sobre la frecuencia con la que se aplican las
actualizaciones o las correcciones de seguridad.

En su lugar, se recomienda instalar Git a través de Homebrew y usar las herramientas

de Homebrew para mantener Git actualizado. Homebrew es una excelente manera de
instalar y administrar herramientas de desarrollo de código abierto en un equipo Mac
desde la línea de comandos.

Instale Homebrew y ejecute lo siguiente para instalar la versión más reciente de Git en
un equipo Mac:

> brew install git

Para actualizar la instalación de Git, use la opción de actualización de Homebrew:

> brew upgrade git

También hay disponible un instalador gráfico para Git en macOS en el sitio web oficial
de Git .

Instalar Git para Linux

Use el sistema de administración de paquetes nativo de la distribución de Linux para
instalar y actualizar Git. Por ejemplo, en Ubuntu:

> sudo apt-get install git

Configurar Git en Linux

Configure el nombre y la dirección de correo electrónico antes de empezar a trabajar
con Git. Git adjunta esta información a los cambios y permite a otros usuarios identificar
qué cambios pertenecen a qué autores.

Ejecute los siguientes comandos desde el símbolo del sistema después de instalar Git
para configurar esta información:

> git config --global [Link] "<First_name> <Last_name>"

> git config --global [Link] "<user_email_address>"

Visual Studio ofrece una excelente experiencia de Git integrada sin ninguna herramienta
adicional. Obtenga más información en este tutorial de Git sobre Visual Studio.
Configurar un repositorio Git
Artículo • 05/10/2023

Un repositorio de Git es una carpeta en la que Git realiza un seguimiento de los

cambios. Puede haber varios repositorios en un equipo, cada uno almacenado en su
propia carpeta. Cada repositorio de Git de un sistema es independiente, por lo que los
cambios guardados en un repositorio de Git no afectan al contenido de otro.

Un repositorio de Git contiene cada versión de cada archivo guardado en el repositorio.

Esto es diferente de otros sistemas de control de versiones que almacenan solo las
diferencias entre los archivos. Git almacena las versiones de archivo en una carpeta .git
oculta junto con otra información que necesita para administrar el código. Git guarda
estos archivos de forma muy eficaz, por lo que tener un gran número de versiones no
significa que utilice una gran cantidad de espacio en disco. Almacenar cada versión de
un archivo ayuda a Git a combinar mejor el código y facilita y agiliza el trabajo con
varias versiones de código.

Los desarrolladores trabajan con Git a través de comandos emitidos mientras trabajan
en un repositorio local en el equipo. Incluso cuando están compartiendo código o
recibiendo actualizaciones del equipo, se hace con comandos que actualizan el
repositorio local. Este diseño centrado en el entorno local es lo que hace que Git sea un
sistema de control de versiones distribuido. Cada repositorio es independiente, y el
propietario del repositorio es responsable de mantenerlo actualizado con los cambios
de otros.
La mayoría de los equipos usan un repositorio central hospedado en un servidor al que
todos los usuarios pueden acceder para coordinar sus cambios. El repositorio central
normalmente se hospeda en una solución de administración de control de código
fuente, como GitHub o Azure DevOps. Una solución de administración de control de
código fuente agrega características y facilita el trabajo en conjunto.

Creación de un repositorio de Git

Tiene dos opciones para crear un repositorio de Git. Puede crear uno a partir del código
de una carpeta de un equipo o clonar uno de un repositorio existente. Si trabaja con
código que está solo en el equipo local, cree un repositorio local con el código de esa
carpeta. La mayoría de las veces, sin embargo, el código ya se comparte en un
repositorio de Git, por lo que se recomienda clonar el repositorio existente en el equipo
local.

Crear un nuevo repositorio a partir de código existente

Use el comando git init para crear un nuevo repositorio a partir de una carpeta
existente en el equipo. En la línea de comandos, vaya a la carpeta raíz que contiene el
código y ejecute:

> git init

para crear el repositorio. A continuación, agregue los archivos de la carpeta a la primera

confirmación mediante los siguientes comandos:

> git add --all

> git commit -m "Initial commit"

Crear un repositorio a partir de un repositorio remoto

Use el comando git clone para copiar el contenido de un repositorio existente en una
carpeta del equipo. En la línea de comandos, vaya a la carpeta que contiene el
repositorio clonado y, a continuación, ejecute:

> git clone

[Link]

Asegúrese de usar la dirección URL real en el repositorio existente en lugar de la

dirección URL de marcador de posición que se muestra en este ejemplo. Esta dirección
URL, denominada dirección URL de clonación, apunta a un servidor donde el equipo
coordina los cambios. Obtenga esta dirección URL del equipo o del botón de clonar del
sitio donde se hospeda el repositorio.

No es necesario agregar archivos ni crear una confirmación inicial cuando se clone el

repositorio, ya que se ha copiado todo, junto con el historial, desde el repositorio
existente durante la operación de clonación.

Pasos siguientes
GitHub y Azure Repos proporcionan repositorios de Git públicos y privados
ilimitados de forma gratuita.

¿Es un usuario de Visual Studio? Obtenga más información sobre cómo crear y clonar
repositorios desde Visual Studio en este tutorial de Git.
Guardado y uso compartido de código
con Git
Artículo • 05/10/2023

Guardar y compartir versiones de código con un equipo son las acciones más comunes
que se realizan al usar el control de versiones. Git tiene un sencillo flujo de trabajo de
tres pasos para estas tareas:

1. Crear una nueva rama para el trabajo

2. Confirmación de cambios
3. Insertar la rama para compartirla con el equipo

Git facilita la administración del trabajo mediante ramas. Cada corrección de errores,
nueva característica, prueba agregada y configuración actualizada comienza con una
nueva rama. Las ramas son ligeras y locales para la máquina de desarrollo, por lo que no
tiene que preocuparse por usar recursos ni coordinar los cambios con otros usuarios
hasta que sea el momento de insertar la rama.

Las ramas le permiten codificar de forma aislada a partir de otros cambios en el

desarrollo. Una vez que todo funciona, la rama y sus cambios se comparten con el
equipo. Los demás pueden experimentar con el código en su propia copia de la rama
sin que afecte al trabajo en curso en sus propias ramas.

Crear una rama

Cree una rama basada en el código de una rama actual, como main , al iniciar un nuevo
trabajo. Es recomendable comprobar qué rama está seleccionada mediante git status
antes de crear una nueva.

Cree ramas en Git usando el comando git branch :

 > git branch <branchname>

El comando para intercambiar entre ramas del repositorio es git checkout . Después de
crear la rama, vaya a ella antes de guardar los cambios.

> git checkout <branchname>

Git tiene un comando abreviado para crear la rama e ir a ella al mismo tiempo:

> git checkout -b <branchname>

Obtenga más información sobre cómo trabajar con ramas de Git en GitHub o Azure
DevOps.

Guardar los cambios

Git no realiza automáticamente instantáneas del código mientras se hacen
modificaciones. Se debe indicar a Git exactamente qué cambios agregar a la siguiente
instantánea. Esto se denomina almacenar provisionalmente. Después de almacenar
provisionalmente los cambios, cree una confirmación para guardar la instantánea
permanentemente.

Almacenar provisionalmente los cambios

Git hace un seguimiento de los cambios de archivo realizados en el repositorio a
medida que se producen. Separa estos cambios en tres categorías:

Los archivos sin modificar no se han cambiado desde la última confirmación.

Los archivos modificados tienen cambios desde la última confirmación, pero no se
han almacenado provisionalmente para la siguiente confirmación.
Los archivos almacenados provisionalmente tienen cambios que se agregarán a la
siguiente confirmación.
Al crear una confirmación, solo se utilizan los cambios almacenados provisionalmente y
los archivos sin cambios para la instantánea. Los cambios no almacenados
provisionalmente se mantienen en el sistema de archivos, pero la confirmación usa el
archivo sin modificar en su instantánea.

Confirmación de cambios
Guarde los cambios en Git mediante la creación de una confirmación. Cada
confirmación almacena todo el contenido del archivo del repositorio en cada
confirmación, no solo los cambios de archivo individuales. Este comportamiento es
diferente de otros sistemas de control de versiones que almacenan las diferencias de
nivel de archivo de la última versión del código. Los historiales completos de archivos
permiten a Git tomar mejores decisiones al combinar los cambios y esto permite que el
cambio entre ramas de código sea extremadamente rápido.

Almacene provisionalmente los cambios con git add para agregar archivos
modificados, git rm para eliminar archivos y git mv para mover archivos. A
continuación, use el comando git commit para crear la confirmación.

Normalmente, los desarrolladores quieren almacenar provisionalmente todos los

archivos modificados en el repositorio:

> git add –all

A continuación, confirme los cambios con una breve descripción:

> git commit -m "Short description of changes."

Cada confirmación tiene un mensaje que describe sus cambios. Un buen mensaje de
confirmación ayuda al desarrollador a recordar los cambios realizados en una
confirmación. Los buenos mensajes de confirmación también facilitan que otros
usuarios revisen la confirmación.

Obtenga más información sobre cómo almacenar archivos provisionalmente y confirmar

cambios en Visual Studio o Visual Studio Code .

Compartir cambios
Tanto si trabajan en un equipo como si solo quieren hacer una copia de seguridad de su
propio código, los desarrolladores deben compartir confirmaciones con un repositorio
en otro equipo. Use el comando git push para tomar confirmaciones del repositorio
local y escribirlas en un repositorio remoto. Git está configurado en repositorios
clonados para conectarse al origen del clon, también conocido como origin . Ejecute
git push para escribir las confirmaciones locales en su rama actual en otra rama

(nombre de rama) en este repositorio de origen. Git crea nombre de rama en el

repositorio remoto si no existe.

> git push origin

Si trabaja en un repositorio creado en el sistema local con git init , deberá configurar
una conexión al servidor de Git del equipo para poder insertar los cambios. Obtenga
más información sobre cómo configurar remotos e insertar cambios en Visual Studio o
Visual Studio Code .

Compartir ramas

Insertar una rama local en el repositorio compartido del equipo permite que sus
cambios sean accesibles para el resto del equipo. La primera vez que se ejecuta git
push , agregar la opción -u indica a Git que empiece a realizar el seguimiento de la rama

local a nombre de rama desde el repositorio origin . Después de esta configuración

única de la información de seguimiento, los miembros del equipo pueden usar git push
directamente para compartir actualizaciones de forma rápida y sencilla.

> git push origin <branchname>

Pasos siguientes
Obtenga más información sobre las ramas en GitHub o Azure DevOps.

Obtenga más información sobre cómo insertar confirmaciones y ramas en Visual Studio
o Visual Studio Code .
Historia de Git
Artículo • 05/10/2023

Git representa el historial de una manera fundamentalmente diferente de los sistemas

de controles de versiones centralizados (CVCS), como el control de versiones de Team
Foundation, Perforce o Subversion. Los sistemas centralizados almacenan un historial
independiente para cada archivo de un repositorio. Git almacena el historial como un
gráfico de instantáneas de todo el repositorio. Estas instantáneas, llamadas
confirmaciones en Git, pueden tener varios elementos primarios, creando un historial
que parece un gráfico en lugar de una línea recta. Esta diferencia en el historial es
increíblemente importante y es la razón principal por la que los usuarios familiarizados
con los CVCS encuentran que Git es confuso.

Conceptos básicos del historial de

confirmaciones
Comience con un ejemplo de historial simple: un repositorio con tres confirmaciones
lineales.

La confirmación A es el elemento primario de la confirmación B y la confirmación B es el

elemento primario de la confirmación C. Este historial es muy similar a un CVCS. La
flecha que apunta a la confirmación C es una rama. Las ramas son punteros a
confirmaciones específicas; por eso, crear una rama es tan ligero y fácil en Git.

Una diferencia clave en Git en comparación con los CVCS es que el desarrollador tiene
su propia copia completa del repositorio. Necesitan mantener su repositorio local
sincronizado con el repositorio remoto obteniendo las últimas confirmaciones del
repositorio remoto. Para hacer esto, tiran de la rama principal con el siguiente comando:

git pull origin main

Esto combina todos los cambios de la rama principal en el repositorio remoto, que Git
denomina origin de forma predeterminada. Esta incorporación de cambios trajo una
nueva confirmación y la rama principal del repositorio local se mueve a esa
confirmación.

Descripción del historial de ramas

Ahora es el momento de realizar un cambio en el código. Es común tener múltiples
ramas activas cuando se trabaja en diferentes características en paralelo. Esto contrasta
con CVCS, donde las ramas nuevas son pesadas y no se suelen crear. El primer paso es
desproteger en una rama nueva mediante este comando:

git checkout -b cool-new-feature

Se trata de un acceso directo que combina dos comandos:

git branch cool-new-feature para crear la rama

git checkout cool-new-feature para empezar a trabajar en la rama

Ahora, dos ramas apuntan a la misma confirmación. Supongamos que hay algunos
cambios en la rama cool-new-feature en dos nuevas confirmaciones, E y F.
La rama cool-new-feature puede acceder a las confirmaciones, ya que se han
confirmado en esa rama. Ahora que la característica está completada, debe combinarse
con la rama principal. Para ello, ejecute el siguiente comando:

git merge cool-feature main

La estructura del gráfico del historial se vuelve visible cuando hay una fusión mediante
combinación. Git crea una nueva confirmación cuando la rama se combina con otra
rama. Se trata de una confirmación de fusión mediante combinación. No hay ningún
cambio incluido en esta confirmación de fusión, ya que no hubo conflictos. Si hubiera
conflictos, la confirmación de fusión incluiría los cambios necesarios para resolverlos.

Historial en el mundo real

Este es un ejemplo de historial de Git que se parece más al código en el desarrollo
activo de un equipo. Hay tres personas que combinan confirmaciones de sus propias
ramas en la rama main al mismo tiempo.

Pasos siguientes
Obtenga más información sobre cómo trabajar con el historial de Git en GitHub y
Azure Repos o la simplificación del historial de registro de Git.
Obtención de comentarios con
solicitudes de incorporación de cambios
Artículo • 05/10/2023

Las solicitudes de incorporación de cambios admiten la revisión y combinación de

código en un único proceso de colaboración. Una vez que un desarrollador agrega una
característica o una corrección de errores, crea una solicitud de incorporación de
cambios para comenzar el proceso de combinar los cambios en la rama ascendente. A
continuación, otros miembros del equipo tienen la oportunidad de revisar y aprobar el
código antes de que se finalice. Use solicitudes de incorporación de cambios para
revisar los trabajos en curso y obtener comentarios sobre los cambios. Pero no hay
ningún compromiso para combinar los cambios. Un propietario puede abandonar una
solicitud de incorporación de cambios en cualquier momento.

Obtención de revisiones de código

La revisión del código realizada como parte de una solicitud de incorporación de
cambios no sirve solo para encontrar errores obvios, ya que para eso sirven las pruebas.
Una buena revisión del código detecta problemas menos obvios que podrían dar lugar
a problemas costosos más adelante.

Las revisiones de código ayudan a proteger al equipo de las combinaciones incorrectas

y las compilaciones rotas que disminuyen la productividad del equipo. Las revisiones
detectan problemas antes de la combinación, protegiendo las ramas importantes de
cambios no deseados.

Las revisiones de código también fomentan y refuerzan la colaboración y la

comunicación entre los desarrolladores. Y el equipo obtiene un historial claro de todos
los cambios realizados entre la rama principal y las ramas de características.

Realice una polinización cruzada de la experiencia y distribuya estrategias de solución

de problemas mediante el uso de una amplia gama de revisores en sus revisiones de
código. La diferenciación de conocimientos y aptitudes hace que el equipo sea más
fuerte y resistente.

Realización adecuada de comentarios

Las revisiones de alta calidad comienzan con comentarios de alta calidad. Las claves
para recibir comentarios excelentes en una solicitud de incorporación de cambios son:
 Pedir a las personas correctas que revisen la solicitud de incorporación de cambios.
Asegurarse de que los revisores saben lo que hace el código.
Proporcionar comentarios útiles y constructivos.
Responda a los comentarios de forma oportuna.

Al asignar revisores a una solicitud de incorporación de cambios, asegúrese de

seleccionar el conjunto correcto de revisores. Los revisores deben saber cómo funciona
el código, pero también incluir a los desarrolladores que trabajan en otras áreas para
que puedan compartir sus ideas.

Proporcione una descripción clara de los cambios y una compilación del código que
incluya la corrección o característica funcionando en ella. Los revisores deben esforzarse
por proporcionar comentarios sobre los cambios con los que no están de acuerdo.
Deben identificar el problema y realizar sugerencias específicas sobre lo que podría
hacerse de forma diferente. Estos comentarios tienen una intención clara y son fáciles de
entender para el propietario de la solicitud de incorporación de cambios.

El propietario de la solicitud de incorporación de cambios debe responder a

comentarios, aceptar sugerencias o explicar por qué rechaza aplicarlas. Algunas
sugerencias son buenas, pero podrían estar fuera del ámbito de la solicitud de
incorporación de cambios. Tome estas sugerencias y cree nuevos elementos de trabajo y
ramas de características independientes de la solicitud de incorporación de cambios
para realizar esos cambios.

Protección de ramas con directivas

Hay algunas ramas críticas en un repositorio que los equipos confían que estarán
siempre en buenas condiciones, como la rama main . Los equipos pueden requerir
solicitudes de incorporación de cambios para realizar cualquier cambio en estas ramas
con plataformas como GitHub y Azure DevOps. Los desarrolladores que inserten
cambios directamente en las ramas protegidas verán rechazados sus envíos.

Agregue condiciones adicionales a las solicitudes de incorporación de cambios para

aplicar un nivel más alto de calidad del código en las ramas clave. Una compilación
limpia del código combinado y la aprobación de varios revisores son algunos requisitos
adicionales que se emplean a menudo para proteger las ramas clave.

Más información
GitHub tiene una amplia documentación sobre cómo proponer cambios en el trabajo
con solicitudes de incorporación de cambios .
Obtenga más información sobre cómo proporcionar comentarios excelentes en las
revisiones de código y cómo usar plantillas de solicitud de incorporación de cambios
para proporcionar instrucciones a los revisores. Azure DevOps también ofrece una
experiencia de solicitud de incorporación de cambios enriquecida que es fácil de usar y
se escala según sea necesario.
Hospedaje de repositorios de Git
Artículo • 29/01/2024

Git se ha convertido rápidamente en el estándar mundial para el control de versiones.

Millones de proyectos dependen de Git para sus necesidades diarias de colaboración.
Aunque la naturaleza descentralizada de Git proporciona importantes ventajas, todavía
es necesario que los equipos inserten sus cambios en un repositorio de Git centralizado
para combinar ramas y proporcionar un centro para otras actividades de DevOps.

GitHub
Hasta ahora, el host líder mundial para proyectos de Git es GitHub . GitHub
proporciona mucho más que el hospedaje de Git. GitHub tiene características que
abarcan todo el proceso de DevOps, incluido un marketplace de productos y servicios
de asociados .

Conozca los conceptos básicos de GitHub en este curso práctico .

Autohospedaje de GitHub
Es posible que algunas organizaciones tengan requisitos normativos o de otro tipo que
les impidan hospedar su código fuente y otros activos fuera de su propia infraestructura.
Estos usuarios tienen disponible GitHub Enterprise Server . GitHub Enterprise Server
incluye las características conocidas y la experiencia de usuario, pero se puede hospedar
completamente dentro de la propia infraestructura de una empresa.

Configure una prueba de GitHub Enterprise Server .

Azure Repos
Los usuarios que ya utilizan Azure DevOps o versiones anteriores de Team Foundation
Server tienen una opción de primera clase para migrar a Azure Repos. Azure Repos
proporciona todas las ventajas de Git, combinadas con una experiencia de usuario y
unos puntos de integración conocidos.

Conozca los conceptos básicos de trabajar con Git en Azure Repos.

Autohospedaje de Azure Repos

Los equipos que necesitan mantener su código fuente y otros activos dentro de su
propia infraestructura pueden usar Azure DevOps Server para disfrutar de todas las
ventajas de Azure Repos.

Descargue la versión más reciente de Azure DevOps Server.

Migrar a Git desde el control de
versiones centralizado
Artículo • 05/10/2023

Para la migración de un equipo a Git desde el control de versiones centralizado se

requiere algo más que aprender nuevos comandos. Para admitir el desarrollo
distribuido, Git almacena el historial de archivos y la información de rama de forma
diferente a un sistema de control de versiones centralizado. Planear e implementar una
migración correcta a Git desde un sistema de control de versiones centralizado requiere
comprender estas diferencias fundamentales.

Microsoft ha ayudado a migrar muchos equipos internos y clientes de sistemas de

control de versiones centralizados a Git. Esta experiencia ha generado las siguientes
instrucciones basadas en la práctica que tuvieron un funcionamiento coherente.

Pasos para la migración correcta

Para una migración correcta, los equipos deben:

Evaluar las herramientas y los procesos actuales.

Seleccionar una estrategia de bifurcación de Git.
Decidir si van a migrar el historial y cómo migrarlo.
Mantener el sistema de control de versiones anterior.
Quitar archivos binarios, ejecutables y herramientas del control de código fuente.
Entrenar a los equipos en los conceptos y prácticas de Git.
Realizar una prueba de la migración a Git.

Evaluar las herramientas y los procesos actuales

El cambio de sistemas de control de versiones naturalmente interrumpe el flujo de
trabajo de desarrollo con nuevas herramientas y prácticas. Esta interrupción puede ser
una oportunidad para mejorar otros aspectos del proceso de DevOps.

Los equipos deben considerar la posibilidad de adoptar las siguientes prácticas cuando
migran al nuevo sistema:

Integración continua (CI), donde cada registro desencadena una compilación y la

superación de una prueba. CI ayuda a identificar los defectos de forma temprana y
proporciona una red de seguridad sólida para los proyectos.
 Revisiones de código necesarias antes de registrar el código. En el modelo de
bifurcación de Git, la revisión del código de solicitud de incorporación de cambios
forma parte del proceso de desarrollo. Las revisiones de código complementan el
flujo de trabajo de CI.

Entrega continua (CD) para automatizar los procesos de implementación. El

cambio de las herramientas de control de versiones requiere cambios en el
proceso de implementación, por lo que una migración es un buen momento para
adoptar una canalización de versión moderna.

Seleccionar una estrategia de bifurcación de Git

Antes de migrar el código, el equipo debe seleccionar una estrategia de bifurcación.

En Git, las ramas de temas de corta duración permiten a los desarrolladores trabajar
cerca de la rama principal e integrar rápidamente, evitando problemas de combinación.
Dos estrategias de rama de temas comunes son GitFlow y una variación más sencilla,
GitHub Flow .

Git desaconseja las ramas de características aisladas de larga duración, que tienden a
retrasar las combinaciones hasta un punto en que la integración resulta difícil. Mediante
el uso de técnicas modernas de CD como las marcas de características, los equipos
pueden integrar código en la rama principal rápidamente, pero continuar ocultando las
características en curso de los usuarios hasta que se completen.

Los equipos que actualmente usan una estrategia de rama de características de larga
duración pueden adoptar las marcas de características antes de migrar a Git. El uso de
marcas de características simplifica la migración minimizando el número de ramas que
se van a migrar. Tanto si usan ramas de características como marcas de características,
los equipos deben documentar la asignación entre ramas heredadas y nuevas ramas de
Git, de modo que todo el mundo comprenda dónde confirmar su nuevo trabajo.

Decidir si se va a migrar el historial

Es posible que los equipos se sientan tentados a migrar su historial de código fuente
existente a Git. Varias herramientas dicen migrar un historial completo de todas las
ramas de una herramienta centralizada a Git. Parece que una confirmación de Git se
asigna relativamente bien al conjunto de cambios o al modelo de registro que usó la
herramienta de control de versiones anterior.

Sin embargo, esta asignación tiene algunas limitaciones graves.

 En la mayoría de los sistemas de control de versiones centralizados, las ramas
existen como carpetas en el repositorio. Por ejemplo, la rama principal podría ser
una carpeta denominada /trunk, y otras ramas son carpetas como /branch/one y
/branch/two. En un repositorio de Git, las ramas incluyen todo el repositorio, por lo
que una traducción 1:1 es difícil.

En algunos sistemas de control de versiones, un tag o label es una colección que

puede contener varios archivos del árbol, incluso archivos en distintas versiones.
En Git, un tag es una instantánea de todo el repositorio en un momento dado. Una
etiqueta no puede representar un subconjunto del repositorio ni combinar
archivos en distintas versiones.

La mayoría de los sistemas de control de versiones almacenan detalles sobre la

forma en que cambian los archivos entre versiones, incluidos tipos de cambio
específicos, como cambiar el nombre, recuperar y revertir. Git almacena las
versiones como instantáneas del repositorio completo y los metadatos sobre la
forma en que cambiaron los archivos no están disponibles.

Estas diferencias significan que una migración completa del historial en el mejor de los
casos será defectuosa y, posiblemente, engañosa. Dado lo anterior, el esfuerzo que
implica y la rareza relativa del uso del historial, se recomienda a la mayoría de los
equipos que eviten importar el historial. En su lugar, los equipos deben realizar una
migración sugerida, llevando solo una instantánea de la versión de rama más reciente a
Git. Para la mayoría de los equipos, es mejor invertir el tiempo en áreas de la migración
que tienen una mayor rentabilidad, como la mejora de los procesos.

Mantenimiento del sistema de control de

versiones anterior
Durante y después de una migración, es posible que los desarrolladores todavía
necesiten tener acceso al historial de control de versiones anterior. Aunque el historial
de control de versiones anterior se vuelve menos relevante con el paso del tiempo,
sigue siendo importante poder consultarlo. Los entornos altamente regulados pueden
tener requisitos legales y de auditoría específicos para el historial de control de
versiones.

Especialmente en el caso de los equipos que realizan solo una migración sugerida, se
recomienda mantener el sistema anterior indefinidamente. Establezca el sistema de
control de versiones anterior en solo lectura después de migrar.

Los equipos de desarrollo grandes y los entornos regulados pueden colocar rutas de
navegación en Git que apunten al antiguo sistema de control de versiones. Un ejemplo
sencillo es un archivo de texto agregado como la primera confirmación en la raíz de un
repositorio de Git, antes de la migración sugerida, que apunta a la dirección URL del
servidor de control de versiones anterior. Si se migran muchas ramas, se debe explicar
en un archivo de texto en cada rama cómo se migraron las ramas del sistema anterior.
Las rutas de navegación también son útiles para los desarrolladores que empiezan a
trabajar en un proyecto después de migrarlo y no están familiarizados con el sistema de
control de versiones anterior.

Eliminación de archivos binarios y herramientas

El modelo de almacenamiento de Git está optimizado para los archivos de texto y el
código fuente del control de versiones, que son compactos y altamente comprimibles.
Los archivos binarios suelen ser grandes y, una vez agregados a un repositorio,
permanecen en el historial del repositorio y en cada clon futuro. Debido a la forma en
que Git almacena el historial, los desarrolladores deben evitar agregar archivos binarios
a repositorios, especialmente archivos binarios muy grandes o que cambian a menudo.
La migración a Git es una oportunidad para quitar estos archivos binarios del código
base.

También se recomienda excluir bibliotecas, herramientas y resultados de compilación de

los repositorios. En su lugar, use sistemas de administración de paquetes como NuGet
para administrar las dependencias.

Es posible que los recursos como iconos y ilustraciones necesiten alinearse con una
versión específica del código fuente. Los recursos pequeños y con poca frecuencia
modificados, como los iconos, no sobredimensionan el historial, y puede incluirlos
directamente en un repositorio. Para almacenar recursos grandes o que cambian con
frecuencia, use la extensión de Almacenamiento de archivos de gran tamaño (LFS) de
Git. Para obtener más información sobre cómo administrar archivos de gran tamaño en
GitHub, consulte Administración de archivos de gran tamaño . Para Azure Repos,
consulte Administrar y almacenar archivos de gran tamaño en Git.

Aprendizaje
Uno de los mayores desafíos para migrar a Git es ayudar a los desarrolladores a
comprender cómo Git almacena los cambios y cómo confirma el historial de desarrollo
de formularios. No es suficiente preparar una hoja de referencia rápida que asigna
comandos antiguos a comandos de Git. Los desarrolladores deben dejar de pensar en el
historial de control de versiones en términos de un modelo centralizado y lineal, y
comprender el modelo de historial y el gráfico de confirmación de Git.
Las personas aprenden de diferentes maneras, por lo que debe proporcionar varios
tipos de materiales de entrenamiento. La formación basada en laboratorio con un
instructor experto funciona bien para algunas personas. El libro Pro Git es un
excelente punto de partida que está disponible gratis en línea.

Entre los cursos prácticos disponibles de forma gratuita se incluyen:

Ruta de aprendizaje Introducción al control de versiones con Git.

El inicio rápido Introducción a Git en Azure Repos.
Recursos de aprendizaje de Git y GitHub de GitHub.

Las organizaciones deben trabajar para identificar a los expertos de Git en los equipos,
capacitarlos para ayudar a los demás y animar a otros miembros del equipo a
formularles preguntas.

Prueba de la migración
Una vez que los equipos actualicen sus procesos, analicen su código y entrenen a sus
miembros, será el momento de migrar el código fuente. Tanto si realiza una migración
sugerida como si migra el historial, es importante realizar una o varias migraciones de
prueba en un repositorio de pruebas. Antes de realizar una migración final, asegúrese
de que:

Se migren todos los archivos de código.

Estén disponibles todas las ramas.
No haya archivos binarios dispersos en el repositorio.
Los usuarios tengan los permisos adecuados para capturar e insertar.
Las compilaciones se realicen correctamente y se superen todas las pruebas.

Migrar el código
Realice la migración final durante horas no laborables, idealmente entre hitos cuando
haya tiempo de inactividad natural. La migración al final de un sprint puede provocar
problemas mientras los desarrolladores intentan finalizar el trabajo. Intente migrar
durante un fin de semana, cuando nadie necesite hacer registros.

Planee una transición firme del sistema de control de versiones anterior a Git. Intentar
operar varios sistemas en paralelo significa que es posible que los desarrolladores no
sepan dónde o cómo registrar. Establezca el sistema de control de versiones anterior en
solo lectura para ayudar a evitar confusiones. Sin esta protección, puede ser necesaria
una segunda migración que incluya los cambios intermedios.
El proceso de migración real varía en función del sistema desde el que se realiza la
migración. Para obtener información sobre la migración desde el control de versiones
de Team Foundation, consulte Migración de TFVC a Git.

Lista de comprobación para la migración

Flujos de trabajo de equipo:

＂ Determine cómo se ejecutarán las compilaciones.

＂ Decida cuándo se ejecutarán las pruebas.
＂ Desarrolle un proceso de administración de versiones.
＂ Mueva las revisiones de código a solicitudes de incorporación de cambios.

Estrategia de ramificación:

＂ Elija una estrategia de bifurcación de Git.

＂ Documente la estrategia de bifurcación, por qué se seleccionó y cómo se asignan
las ramas heredadas.

Historial:

＂ Decida cuánto tiempo debe mantener en ejecución el control de versiones

heredado.
＂ Identifique las ramas que es necesario migrar.
＂ Si es necesario, cree rutas de navegación para ayudar a los ingenieros a volver al
sistema heredado.

Archivos binarios y herramientas:

＂ Identifique los archivos binarios y los archivos que no se pueden comparar que hay
que quitar del repositorio.
＂ Decida un enfoque para archivos grandes, como Git-LFS.
＂ Decida un enfoque para entregar herramientas y bibliotecas, como NuGet.

Entrenamiento:

＂ Identifique los materiales de entrenamiento.

＂ Planee eventos de entrenamiento, materiales escritos y vídeos.
＂ Identifique a los miembros del equipo que actuarán como expertos locales de Git.

Migración del código:

＂ Realice varias ejecuciones de prueba para asegurarse de que la migración se

realizará sin problemas.
＂ Identifique y comunique un tiempo de transición.
＂ Cree el nuevo repositorio Git.
＂ Establezca el sistema antiguo en solo lectura.
＂ Migre primero la rama principal y, a continuación, cualquier otra rama necesaria.

Pasos siguientes
Migración a Azure DevOps desde Team Foundation Server
Cómo se asignan los comandos y flujos de trabajo de TFVC a Git
Importación y migración de repositorios
de TFVC a Git
Artículo • 26/08/2023

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019 | TFS
2018

Puede migrar código de un repositorio TFVC existente a un nuevo repositorio de Git

dentro de la misma organización. La migración a Git es un proceso implicado para
grandes repositorios y equipos de TFVC. Los sistemas de control de versiones
centralizados, como TFVC, se comportan de forma diferente de Git de maneras
fundamentales. El cambio implica mucho más que aprender nuevos comandos. Es un
cambio disruptivo para el que se necesita una planificación cuidadosa. Debe pensar en
lo siguiente:

Revisar herramientas y procesos

Quitar archivos binarios y ejecutables
Entrenar al equipo

Se recomienda encarecidamente leer la documentación sobre Control de versiones

centralizado a Git y la sección Migración de TFVC a Git antes de iniciar la migración.

La experiencia de importación es excelente para pequeños repositorios TFVC sencillos.

También se recomienda para los repositorios que ya se han "limpiado", como se
describe en Control de versiones centralizado a Git y en la sección Migración de TFVC a
Git . En estas secciones también se recomiendan otras herramientas para
configuraciones de repositorio de TFVC más avanzadas.

） Importante

Dadas las diferencias en la forma en que TFVC y Git almacenan la información del
control de versiones, se recomienda que no migre el historial. Este es el enfoque
que Microsoft adoptó cuando migró tanto Windows como otros productos desde
el control de versiones centralizado a GIT.

Importación del repositorio

1. Seleccione Repositorios > Archivos.
2. En la lista desplegable del repositorio, seleccione Importar repositorio.

3. Seleccione TFVC en la lista desplegable Tipo de origen

4. Escriba la ruta de acceso al repositorio, rama o carpeta que quiera importar al

repositorio de Git. Por ejemplo: $/Fabrikam/FabrikamWebsite

5. Si quiere migrar el historial desde el repositorio de TFVC, haga clic en Migrar

historial y seleccione el número de días. Puede migrar hasta 180 días de historial a
partir del conjunto de cambios más reciente. Se agrega un vínculo al repositorio de
 TFVC en el mensaje de confirmación del primer conjunto de cambios que se migra
a Git. Esto facilita la búsqueda de historiales más antiguos cuando sea necesario.

6. Asigne un nombre al nuevo repositorio de Git y haga clic en Importar. Según el

tamaño de la importación, el repositorio de Git estará listo en unos minutos.

Solución de problemas
Esta experiencia está optimizada para repositorios pequeños y sencillos de TFVC o
repositorios o que se hayan preparado para una migración. Esto significa que tiene
algunas limitaciones.

1. Solo se migra el contenido de la raíz o de una rama. Por ejemplo, si tiene un

proyecto de TFVC en $/Fabrikam con una rama y una carpeta, una ruta de acceso a
la importación $/Fabrikam importaría la carpeta, mientras que
$/Fabrikam/<branch> solo importaría la rama.

2. El repositorio importado y el historial asociado (si se importa) no pueden superar

1 GB de tamaño.
3. Puede importar hasta 180 días del historial.

Si alguna de estas limitaciones le impide realizar la importación, le recomendamos

utilizar herramientas externas como Git-TFS para la importación y que consulte
nuestros documentos - Control de versiones centralizado a Git y la sección Migración de
TFVC a Git.

） Importante

El uso de herramientas externas como Git-TFS con productos, servicios o

plataformas de Microsoft es responsabilidad total del usuario. Microsoft no
aprueba, admite ni garantiza la funcionalidad, confiabilidad ni seguridad de dichas
extensiones de terceros.

Migración de TFVC a Git

Antes de migrar el código fuente desde un sistema de control de versiones centralizado
a Git, comprenda las diferencias entre los dos y prepárese para la migración.

Requisitos
Pasos para la migración
Comprobación de la versión más reciente
Eliminación de archivos binarios y herramientas de compilación
Conversión de la configuración específica del control de versiones
Comprobación de los cambios y realización de la migración
Migraciones avanzadas
Actualización del flujo de trabajo

Requisitos
Para facilitar las migraciones, hay varios requisitos antes de seguir el procedimiento de
importación del repositorio en la sección anterior de este artículo.

Migre una sola rama. Al planear la migración, elija una nueva estrategia de
ramificación para Git. La migración solo de la rama principal admite un flujo de
trabajo basado en rama de temas, como GitFlow o GitHub Flow .
Realice una migración sugerida, es decir, importe solo la versión más reciente del
código fuente. Si el historial de TFVC es sencillo, hay una opción para migrar algún
historial, hasta 180 días, para que el equipo pueda trabajar solo con Git. Para
obtener más información, consulte Planificación de la migración a Git.
Excluya los activos binarios como las imágenes, los conjuntos de datos científicos o
los modelos de juego del repositorio. Estos activos deben usar la extensión LFS
(almacenamiento de archivos grandes) de Git, que la herramienta de importación
no configura.
 Mantenga el tamaño del repositorio importado por debajo de 1 GB.

Si el repositorio no cumple estos requisitos, use la herramienta Git-TFS para realizar la

migración.

） Importante

El uso de herramientas externas como Git-TFS con productos, servicios o

plataformas de Microsoft es responsabilidad total del usuario. Microsoft no
aprueba, admite ni garantiza la funcionalidad, confiabilidad ni seguridad de dichas
extensiones de terceros.

Pasos para la migración

El proceso de migración desde TFVC suele ser sencillo:

1. Consulte la versión más reciente de la rama desde TFVC en el disco local.

2. Elimine los archivos binarios y las herramientas de compilación del repositorio y
configure un sistema de administración de paquetes como NuGet.
3. Convierta las directivas de configuración específicas del control de versiones. Por
ejemplo, convierta .tfignore archivos en .gitignore y .tpattributes archivos en
.gitattributes .
4. Compruebe los cambios y realice la migración a Git.

Los pasos del 1 al 3 son opcionales. Si no hay archivos binarios en el repositorio y no es

necesario configurar .gitignore o .gitattributes , puede continuar directamente con
el paso Compruebe los cambios y realice la migración.

Comprobación de la versión más reciente

Cree un área de trabajo TFS y asigne una carpeta de trabajo para el directorio del
servidor que se va a migrar a Git. Esto no requiere una asignación completa de las
carpetas de trabajo. Solo las carpetas de asignación que contienen archivos binarios a
eliminar del repositorio y las carpetas que contienen archivos de configuración
específicos del sistema de control de versiones, como .tfignore .

Una vez configuradas las asignaciones, obtenga la carpeta localmente:

prettyprint

tf get /version:T /recursive

Eliminación de archivos binarios y herramientas de compilación
Debido a la forma en la que Git almacena el historial de archivos modificados
proporcionando una copia de cada archivo del historial a cada desarrollador, la
comprobación de archivos binarios directamente en el repositorio hace que el
repositorio crezca rápidamente y puede causar problemas de rendimiento.

Para herramientas de compilación y dependencias como bibliotecas, adopte una

solución de empaquetado con compatibilidad de versiones, como NuGet. Muchas
bibliotecas y herramientas de código abierto ya están disponibles en la Galería de
NuGet , pero para las dependencias propietarias, cree nuevos paquetes NuGet.

Una vez que las dependencias se mueven a NuGet, asegúrese de que no se incluyen en
el repositorio de Git al agregarlas a .gitignore.

Conversión de la configuración específica del control de versiones

Control de versiones de Team Foundation proporciona un archivo .tfignore , lo que

garantiza que determinados archivos no se agreguen al repositorio TFVC. Puede usar el
archivo .tfignore para archivos generados automáticamente como la salida de
compilación para que no se registren accidentalmente.

Si el proyecto se basa en este comportamiento, convierta el archivo .tfignore en un

archivo .gitignore.

Los clientes TFVC multiplataforma también proporcionan compatibilidad con un archivo

.tpattributes , que controla cómo se colocan los archivos en el disco local o cómo se

registran en el repositorio. Si un archivo .tpattributes está en uso, conviértalo en un

archivo .gitattributes .

Comprobación de los cambios y realización de la migración

Compruebe los cambios que eliminen archivos binarios, migren a la administración de
paquetes o conviertan la configuración específica del control de versiones. Una vez
realizado este cambio final en TFVC, puede realizar la importación.

Siga el procedimiento Importación del repositorio para realizar la importación.

Migraciones avanzadas
La herramienta Git-TFS es un puente bidireccional entre Control de versiones de Team
Foundation y Git, y puede usarla para realizar una migración. Git-TFS es adecuado para
una migración con historial completo, más de los 180 días que admite la herramienta de
importación. También puede usar Git-TFS para intentar hacer una migración que incluya
varias ramas y relaciones de combinación.

Antes de intentar realizar una migración con Git-TFS, tenga en cuenta que hay
diferencias fundamentales entre la forma en la que TFVC y Git almacenan el historial:

Git almacena el historial como una instantánea del repositorio en el tiempo,

mientras que TFVC registra las operaciones discretas que se produjeron en un
archivo. Los tipos de cambios en TFVC, como cambiar el nombre, recuperar
eliminaciones y revertir acciones, no se pueden expresar en Git. En lugar de ver
que el nombre del archivo A se cambió a B , solo registra que el archivo A se
eliminó y que el archivo B se agregó en la misma confirmación.
Git no tiene un análogo directo de una etiqueta TFVC. Las etiquetas pueden
contener cualquier número de archivos en cualquier versión específica y pueden
reflejar archivos en diferentes versiones. Aunque conceptualmente son similares,
las etiquetas de Git apuntan a una instantánea del repositorio completo en un
momento dado. Si el proyecto se basa en etiquetas TFVC para saber qué se ha
entregado, es posible que las etiquetas de Git no proporcionen esta información.
Las combinaciones en TFVC se producen en el nivel de archivo, no en todo el
repositorio. Solo se puede combinar un subconjunto de archivos modificados de
una rama a otra. Los archivos modificados restantes se pueden combinar en un
conjunto de cambios posterior. En Git, una combinación afecta a todo el
repositorio y ambos conjuntos de cambios individuales no se pueden ver como
una combinación.

Debido a estas diferencias, se recomienda realizar una migración sugerida y mantener el

repositorio TFVC en línea, pero de solo lectura, para ver el historial.

Para intentar hacer una migración avanzada con Git-TFS, consulte Clonación de una sola
rama con historial o Clonación de todas las ramas con historial combinado .

） Importante

El uso de herramientas externas como Git-TFS con productos, servicios o

plataformas de Microsoft es responsabilidad total del usuario. Microsoft no
aprueba, admite ni garantiza la funcionalidad, confiabilidad ni seguridad de dichas
extensiones de terceros.

Actualización del flujo de trabajo

Pasar de un sistema de control de versiones centralizado a Git implica algo más que
simplemente migrar código. El equipo necesita entrenamiento para comprender en qué
se diferencia Git del sistema de control de versiones existente y cómo estas diferencias
afectan el trabajo diario.

Obtenga más información sobre cómo migrar del control de versiones centralizado a
Git.

Comentarios
¿Le ha resultado útil esta página?  Sí  No

Proporcionar comentarios sobre el producto

Uso de la integración continua
Artículo • 05/10/2023

La integración continua (CI) es el proceso de crear automáticamente compilaciones y

pruebas de código cada vez que un miembro del equipo confirma cambios en el control
de versiones. Una confirmación de código en la rama principal o troncal de un
repositorio compartido activa el sistema de compilación automatizado para compilar,
probar y validar la rama completa. La CI anima a los desarrolladores a que compartan el
código y las pruebas unitarias, ya que incorpora sus cambios en el repositorio de control
de versiones compartido después de terminen cada tarea.

Los desarrolladores de software suelen trabajar de forma aislada y luego necesitan

integrar los cambios en el resto de la base del código de un equipo. Si se esperan días o
semanas para integrar código, esto puede generar muchos conflictos de combinación,
dificultades para corregir errores, que se apliquen diferentes estrategias de código y se
dupliquen los esfuerzos. La CI evita estos problemas porque requiere que el código del
equipo de desarrollo se combine continuamente con la rama de control de versiones
compartida.

La CI tiene siempre actualizada la rama principal. Los desarrolladores pueden usar

sistemas de control de versiones modernos como Git para aislar su trabajo en ramas de
funciones de corta duración. Terminada la función, el desarrollador envía una solicitud
de incorporación de cambios de la rama de la función a la rama principal. Al aprobar la
solicitud de incorporación de cambios, los cambios se combinan en la rama principal y
se puede eliminar la rama de la función.

Los equipos de desarrollo repiten este proceso por cada instancia de trabajo. Los
equipos pueden crear directrices de rama para asegurarse de que la rama principal
respeta los criterios de calidad deseados.

Las definiciones de compilaciones indican que todas las confirmaciones en la rama

principal activan el proceso automatizado de compilación y pruebas. Las pruebas
automatizadas comprueban que cada compilación presenta una calidad uniforme. La CI
detecta los errores antes en el ciclo de desarrollo, por lo que incurren en menos costes
al corregirlos.

La CI es una funcionalidad estándar en plataformas modernas de DevOps. Los usuarios

de GitHub pueden implementar la CI a través de Acciones de GitHub . Los usuarios de
Azure DevOps pueden usar Azure Pipelines .
Desplazamiento a la izquierda de las
pruebas con pruebas unitarias
Artículo • 05/10/2023

Las pruebas ayudan a garantizar que el código funcione según lo previsto, pero el
tiempo y el esfuerzo para compilar pruebas emplean tiempo de otras tareas, como el
desarrollo de funciones. Por este motivo, es importante sacarles el máximo valor a las
pruebas. En este artículo se describen los principios de las prueba de DevOps,
centrándose en el valor de las pruebas unitarias y en una estrategia de prueba de
desplazamiento a la izquierda.

Los probadores específicos solían escribir la mayoría de pruebas y muchos

desarrolladores de productos no aprendían a escribir pruebas unitarias. Escribir pruebas
puede parecer demasiado difícil o demasiado laborioso. Pueden surgir dudas sobre si
una estrategia de prueba unitaria funcionara, malas experiencias con pruebas unitarias
mal escritas o miedo a que las pruebas unitarias reemplacen las pruebas funcionales.

Para implementar una estrategia de prueba de DevOps, actúe de forma pragmática y

céntrese en darle dinamismo. Aunque puede hacer hincapié en pruebas unitarias de
código nuevo o código existente que se pueden refactorizar de forma limpia, tendría
sentido que un código base heredado permita alguna dependencia. Si las partes
significativas del código de producto usan SQL, permitiendo que las pruebas unitarias
tomen dependencias en el proveedor de recursos de SQL en lugar de simular esa capa,
podría ser una estrategia a corto plazo para progresar.
A medida que las organizaciones de DevOps maduran, resulta más fácil para los
responsables mejorar los procesos. Aunque puede haber cierta resistencia al cambio, las
organizaciones ágiles valoran los cambios que sean claramente rentables. Las
ejecuciones de pruebas más rápidas con menos errores deberían ser algo más atractivo,
ya que implica más tiempo para invertir en generar un nuevo valor a través del
desarrollo de funciones.

Taxonomía de pruebas de DevOps

Definir la taxonomía de una prueba es muy importante en los procesos de pruebas de
DevOps. La taxonomía de una prueba de DevOps clasifica las pruebas individuales por
sus dependencias y el tiempo que tardan en ejecutarse. Los desarrolladores deben
conocer los tipos correctos de pruebas que se vayan a usar en diferentes casos y qué
pruebas necesitan de diferentes partes del proceso. La mayoría de organizaciones
dividen las pruebas en cuatro niveles:

Las pruebas L0 y L1 son pruebas unitarias o pruebas que dependen del código del
ensamblado que se somete a prueba y nada más. Las L0 son una amplia clase de
pruebas unitarias rápidas en memoria.
Las L2 son pruebas funcionales que podrían necesitar el ensamblado, así como
otras dependencias, como SQL o el sistema de archivos.
Las L3 son pruebas funcionales que se ejecutan en implementaciones de servicio
que se pueden probar. Esta categoría de prueba precisa una implementación de
servicio, pero puede usar códigos auxiliares para las dependencias de servicio
principales.
Las pruebas L4 son una clase restringida de pruebas de integración que se ejecutan
en fase de producción. Para las pruebas L4 se necesita una implementación
completa del producto.

Aunque sería ideal para que todas las pruebas se ejecuten en todo momento, esto no es
factible. Los equipos pueden seleccionar en qué punto se encuentra el proceso de
DevOps para ejecutar cada prueba y usar estrategias de desplazamiento a la izquierda o
de desplazamiento a la derecha para mover diferentes tipos de prueba anteriores o
posteriores en el proceso.

Por ejemplo, la que se busca podría ser que los desarrolladores siempre ejecuten las
pruebas L2 antes de confirmar, se produce un error automáticamente en una solicitud
de incorporación de cambios si se produce un error en la ejecución de pruebas L3 y la
implementación podría bloquearse si se produce un error en las pruebas L4. Las reglas
específicas pueden variar de una organización a otra, pero aplicar las expectativas de
todos los equipos de una organización dirige a todos hacia los mismos objetivos de
calidad.

Directrices de pruebas unitarias

Cree directrices estrictas para las pruebas unitarias L0 y L1. Estas pruebas deben ser muy
rápidas y fiables. Por ejemplo, el tiempo medio de ejecución por prueba L0 en un
ensamblado debe ser inferior a 60 milisegundos. El tiempo medio de ejecución por
prueba L1 en un ensamblado debe ser inferior a 400 milisegundos. Ninguna prueba en
este nivel debe superar los 2 segundos.

Un equipo de Microsoft ejecuta más de 60 000 pruebas unitarias en paralelo en menos

de seis minutos. Su objetivo es reducir este tiempo a menos de un minuto. El equipo
realiza un seguimiento del tiempo de ejecución de pruebas unitarias con herramientas
como la siguiente gráfica y archivos de errores en las pruebas que superan el tiempo
permitido.

Directrices de pruebas funcionales

Las pruebas funcionales deben ser independientes. El concepto clave de las pruebas L2
es el aislamiento. Las pruebas aisladas se pueden ejecutar correctamente y de forma
fiable en cualquier secuencia, ya que tienen control completo sobre el entorno en el que
se ejecutan. El estado debe conocerse al principio de la prueba. Si una prueba ha creado
datos y los ha dejado en la base de datos, esto podría afectar negativamente la
ejecución de otra prueba que se base en un estado de base de datos diferente.
Las pruebas heredadas que necesitan una identidad de usuario podrían haber llamado a
proveedores de autenticación externos para obtener la identidad. Esta práctica presenta
varios desafíos. La dependencia externa podría no ser fiable o no estar disponible
momentáneamente, lo que podría interrumpir la prueba. Esta práctica también infringe
el principio de aislamiento de prueba, ya que una prueba podría cambiar el estado de
una identidad, como el permiso, lo que da lugar a un estado predeterminado
inesperado para otras pruebas. Plantéese la posibilidad de evitar estos problemas
poniendo atención a la compatibilidad con la identidad en el marco de pruebas.

Principios de pruebas de DevOps

Para realizar la transición de una cartera de pruebas a procesos modernos de DevOps,
elabore una estrategia de calidad. Los equipos deben cumplir los siguientes principios
de pruebas al definir e implementar una estrategia de pruebas de DevOps.

Desplazamiento a la izquierda para hacer las pruebas en

una fase anterior
Las pruebas pueden tardar mucho tiempo en ejecutarse. A medida que los proyectos
escalan, el número de prueba y los tipos aumentan considerablemente. Cuando los
conjuntos de pruebas crecen y duran horas o días en completarse, pueden pasar a una
etapa más tardía hasta que se ejecuten en el último momento. Las ventajas de la calidad
del código de las pruebas no se sacan hasta pasado mucho tiempo después de
confirmar el código.

Las pruebas de larga duración también pueden producir errores que necesitan de
mucho tiempo para investigar. Los equipos pueden crear tolerancia frente a errores,
especialmente al principio de los sprints. Esta tolerancia debilita el valor de las pruebas
como barómetro sobre la calidad del código base. Las pruebas de larga duración y de
última hora también hacen las expectativas de final de sprint sean impredecibles, ya que
se debe pagar una cantidad desconocida de deuda técnica para obtener el código
entregable.

El objetivo para desplazar las pruebas a la izquierda es mover la calidad de forma

ascendente mediante la realización de tareas de prueba anteriormente en el proceso. A
través de una combinación de pruebas y mejoras de procesos, el desplazamiento a la
izquierda reduce el tiempo que tardan en ejecutarse las pruebas y el impacto de los
errores más adelante en el ciclo. El desplazamiento a la izquierda garantiza que la
mayoría de pruebas se completan antes de que se combine un cambio en la rama
principal.

Además de cambiar ciertas responsabilidades de pruebas de desplazamiento a la

izquierda para mejorar la calidad del código, los equipos pueden cambiar otros
aspectos de las pruebas hacia la derecha, o más adelante en el ciclo de DevOps, para
mejorar el producto final. Para obtener más información, consulte Desplazamiento a la
derecha de las pruebas en fase de producción.

Escribir pruebas en el nivel más bajo posible

Escriba más pruebas unitarias. Favorezca las pruebas con las pocas dependencias
externas y céntrese en ejecutar la mayoría de las pruebas como parte de la compilación.
Piense en un sistema de compilación paralelo que pueda ejecutar pruebas unitarias en
un ensamblado en cuanto se retiren el ensamblado y las pruebas asociadas. No resulta
viable probar todos los aspectos de un servicio en este nivel, pero lo esencial es usar
pruebas unitarias más ligeras si pueden dar los mismos resultados que las pruebas
funcionales más pesadas.

Buscar más fiabilidad en las pruebas

Una prueba que no es fiable le resulta costosa de mantener a la organización. Esta
prueba gira directamente en torno al objetivo de eficacia de ingeniería haciendo que
sea difícil realizar cambios con confianza. Los desarrolladores deben poder realizar
cambios en cualquier lugar y estar convencidos al instante de que no se ha roto nada.
Mantenga unos niveles de calidad altos para favorecer la fiabilidad. Desincentive el uso
de pruebas de IU, ya que tienden a no ser fiables.

Escribir pruebas funcionales que se pueden ejecutar en

cualquier lugar
Las pruebas pueden usar puntos de integración especializados diseñados
específicamente para habilitar las pruebas. Una razón para realizar esta práctica es la
falta de capacidad de hacer pruebas en el propio producto. Desafortunadamente, las
pruebas como estas suelen depender de conocimientos internos y usar datos de
implementación que no importan desde una perspectiva de prueba funcional. Estas
pruebas se limitan a entornos que tienen los secretos y los ajustes necesarios para
ejecutar las pruebas, que generalmente excluyen las implementaciones de producción.
Las pruebas funcionales solo deben usar la API pública del producto.

Diseñar productos para que se puedan probar

Las organizaciones con un proceso de DevOps ya maduro tienen una visión completa
de lo que significa ofrecer un producto de calidad según la cadencia de la nube. Si se
produce una descompensación a favor de las pruebas unitarias sobre las pruebas
funcionales, los equipos se verán obligados a optar por diseños e implementaciones
que incluyan la posibilidad de probarse. Hay diferentes ideas sobre lo que constituye
código bien diseñado y bien implementado para favorecer su capacidad de someterse a
prueba, al igual que hay diferentes estilos de codificación. La teoría establece que
adaptar el diseño a su capacidad de prueba debe convertirse en la clave en las
cuestiones sobre el diseño y la calidad del código.

Considerar el código de prueba como código de

producto
Al afirmar expresamente que el código de prueba es código de producto, queda claro
que la calidad del código de prueba es tan importante en la entrega como en la del
código del producto. Los equipos deben tratar el código de prueba de la misma manera
que tratan el código del producto y ponerle el mismo nivel de atención al diseño e
implementación de pruebas y a los marcos de pruebas. Esto es similar a administrar la
configuración y la infraestructura como código. Para finalizar, la revisión de un código
debe tener en cuenta el código de prueba y categorizarlo en el mismo nivel de calidad
que el código del producto.

Usar la infraestructura de pruebas compartidas

Facilite el proceso usando una infraestructura de pruebas para generar indicios de
calidad de confianza. Vea las pruebas como un servicio compartido para todo el equipo.
Almacene el código de las pruebas unitarias junto con el código del producto y
compílelo con el producto. Las pruebas que se ejecutan como parte del proceso de
compilación también deben ejecutarse en herramientas de desarrollo como Azure
DevOps. Si las pruebas se pueden ejecutar en todos los entornos a partir de la fase de
desarrollo local en la fase de producción, tendrán la misma fiabilidad que el código del
producto.

Hacer que los propietarios del código sean responsables

de las pruebas
El código de prueba debe residir junto al código del producto en un repositorio. Para
que el código se pruebe en un límite de componente, traslade la responsabilidad de las
pruebas a la persona que escriba el código del componente. No confíe en otros
usuarios para probar el componente.

Caso práctico: Desplazamiento a la izquierda

con pruebas unitarias
Un equipo de Microsoft decidió reemplazar sus conjuntos de pruebas heredados por
pruebas unitarias modernas de DevOps y un proceso de desplazamiento a la izquierda.
El equipo llevó un control del progreso entre sprints cada tres semanas, tal como se
muestra en la gráfica siguiente. La gráfica incluye sprints de 78 a 120, equivalente a 42
sprints durante 126 semanas, o aproximadamente dos años y medio de trabajo.

El equipo comenzó con 27 000 pruebas heredadas en el sprint 78 y alcanzó cero

pruebas heredadas en S120. Un conjunto de pruebas unitarias L0 y L1 reemplazó la
mayoría de pruebas funcionales antiguas. Las nuevas pruebas L2 reemplazaron algunas
de las pruebas y muchas de las pruebas antiguas se eliminaron.

En el recorrido de un software que tarda más de dos años en completarse, hay mucho
que aprender del propio proceso. En general, el esfuerzo por rehacer completamente el
sistema de pruebas a lo largo de dos años supuso una inversión enorme. No todos los
equipos de funciones trabajaron al mismo tiempo. Muchos equipos de la organización
invirtieron tiempo en cada sprint y, en algunos sprints, el equipo empleó total
dedicación. Aunque es difícil medir los costes del cambio, fue un requisito no
negociable en favor de los objetivos de calidad y el rendimiento del equipo.

Primeros pasos
Al principio, el equipo dejó por una lado las pruebas funcionales antiguas, llamadas
pruebas TRA. El equipo quería que los desarrolladores asimilaran la idea de escribir
pruebas unitarias, especialmente para nuevas funciones. El objetivo era facilitar la
creación de pruebas L0 y L1. El equipo necesitaba desarrollar esa capacidad en primer
lugar y ganar impulso.

En la gráfica anterior se muestra el número de pruebas unitarias que empiezan a

aumentar al principio, cuando el equipo descubrió la ventaja de crear pruebas unitarias.
Las pruebas unitarias fueron más fáciles de mantener, más rápidas de ejecutar y tenían
menos errores. Era fácil obtener ayuda con la ejecución de todas las pruebas unitarias
en el flujo de solicitud de incorporación de cambios.

El equipo no se centró en escribir nuevas pruebas L2 hasta el sprint 101. Mientras tanto,
el número de pruebas TRA pasó de 27 000 a 14 000 del sprint 78 al sprint 101. Las
nuevas pruebas unitarias reemplazaron algunas de las pruebas TRA, pero muchas se
eliminaron, en función de lo útiles que le parecieran al equipo.

Las pruebas TRA pasaron de 2100 a 3800 en el sprint 110 porque se detectaron más
pruebas en el árbol de origen y se añadieron a la gráfica. Se observó que las pruebas
siempre se habían estado ejecutando, pero no se hacía un seguimiento correcto. Esto no
era una crisis, pero había que ser honesto y era necesario hacer una reevaluación donde
fuera necesario.
Usar procesos más rápidos
Cuando el equipo se creó un modelo de integración continua (CI) que fuera
extremadamente rápida y fiable, se convirtió en un parámetro de confianza para la
calidad del producto. En la captura de pantalla siguiente podemos ver la solicitud de
incorporación de cambios y el proceso de CI en acción, así como el tiempo necesario
para pasar por las diferentes fases.

La solicitud de incorporación de cambios tarda unos 30 minutos en combinarse, lo que

implica la ejecución de 60 000 pruebas unitarias. La combinación del código en la
compilación de CI tarda aproximadamente 22 minutos. El primer indicio de calidad de la
CI, SelfTest, viene después de alrededor de una hora. A continuación, la mayor parte del
producto se prueba con el cambio propuesto. En un plazo de dos horas de Merge a
SelfHost, se prueba todo el producto y el cambio está listo para entrar en producción.

Uso de métricas
El equipo realiza un seguimiento con una ficha de evaluación como se ve en el ejemplo
siguiente. En un nivel alto, la ficha de evaluación hace uso de dos tipos de métricas:
estado o deuda y velocidad.
En el caso de las métricas de estado del sitio activo, el equipo realiza un seguimiento del
tiempo de detección, el tiempo de mitigación y el número de instancias de reparación
que lleva un equipo. Una instancia de reparación es el trabajo que el equipo identifica
en un análisis del sitio activo para evitar que se repitan incidencias similares. La ficha de
evaluación también controla si los equipos cierran las instancias de reparación dentro de
un período de tiempo razonable.

En el caso de las métricas de estado de las tareas de ingeniería, el equipo realiza un

seguimiento de los errores activos por desarrollador. Si un equipo tiene más de cinco
errores por desarrollador, el equipo debe priorizar la corrección de esos errores antes de
desarrollar nuevas funciones. El equipo también lleva un control de errores antiguos en
categorías especiales, como la seguridad.

Las métricas de velocidad de ingeniería calculan la velocidad en diferentes partes del

proceso de integración continua y entrega continua (CI/CD). El objetivo general es
aumentar la velocidad del proceso de DevOps: concepción de una idea, inserción del
código en la fase de producción y recepción de datos de los clientes.

Pasos siguientes
Ruta de aprendizaje: Creación de aplicaciones con Azure DevOps
Uso de la integración continua
Desplazamiento a la derecha para ejecutar pruebas en producción
Las simulaciones no son códigos auxiliares
Desarrollo de Microsoft con DevOps
Artículo • 05/10/2023

Microsoft se esfuerza por utilizar One Engineering System para compilar e implementar
todos los productos de Microsoft con un proceso sólido de DevOps centrado en un
flujo de ramificación y versión de Git. En este artículo se destaca la implementación
práctica, cómo el sistema se escala desde los servicios pequeños hasta las necesidades
de desarrollo de plataformas masivas y las lecciones aprendidas del uso del sistema en
varios equipos de Microsoft.

La adopción de un proceso de desarrollo estandarizado es una tarea ambiciosa. Los

requisitos de diferentes organizaciones de Microsoft varían considerablemente y los
requisitos de diferentes equipos dentro de las organizaciones se escalan en tamaño y
complejidad. Para satisfacer estas distintas necesidades, Microsoft utiliza una estrategia
de ramificación troncal para ayudar a desarrollar los productos rápidamente,
implementarlos con regularidad y entregar cambios de forma segura en producción.

Flujo de versiones de Microsoft

Cada organización debe establecerse en un proceso estándar de lanzamiento de
versiones de código para garantizar la coherencia entre los equipos. El flujo de versiones
de Microsoft incorpora procesos de DevOps desde el desarrollo hasta el lanzamiento.
Los pasos básicos del flujo de versiones constan de ramificación, inserción, solicitud de
incorporación de cambios y combinación.

Rama
Para corregir un error o implementar una característica, un desarrollador crea una nueva
rama fuera de la rama de integración principal. El modelo de ramificación ligera de Git
crea estas ramas puntuales de corta duración para cada contribución de código. Los
desarrolladores confirman de forma temprana y evitan ramas de características de
ejecución larga mediante marcas de características.

Push
Cuando el desarrollador está listo para integrar y enviar los cambios al resto del equipo,
inserta su rama local en una rama del servidor y abre una solicitud de incorporación de
cambios. Los repositorios que tienen varios cientos de desarrolladores trabajando en
muchas ramas usan una convención de nomenclatura para las ramas del servidor a fin
de mitigar la confusión y la proliferación de ramas. Normalmente, los desarrolladores
crean ramas denominadas users/<username>/feature , donde <username> es su nombre
de cuenta.

Solicitud de incorporación de cambios

Las solicitudes de incorporación de cambios controlan las combinaciones de ramas
puntuales con la rama principal y aseguran que se cumplan las directivas de rama. El
proceso de solicitud de incorporación de cambios compila los cambios propuestos y
ejecuta una prueba rápida superada. Los conjuntos de pruebas de primer y segundo
nivel ejecutan alrededor de 60 000 pruebas en menos de cinco minutos. Esta no es la
matriz de pruebas de Microsoft completa, pero es suficiente para dar confianza
rápidamente en las solicitudes de incorporación de cambios.

A continuación, otros miembros del equipo revisan el código y aprueban los cambios. La
revisión de código continúa desde donde lo dejaron las pruebas automatizadas y es
especialmente útil para detectar problemas arquitectónicos. Las revisiones manuales de
código aseguran que otros ingenieros del equipo tengan visibilidad sobre los cambios y
que la calidad del código siga siendo alta.

Merge
Una vez que la solicitud de incorporación de cambios satisface todas las directivas de
compilación y los revisores han dado su aprobación, la rama puntual se combina con la
rama de integración principal y se completa la solicitud de incorporación de cambios.

Después de la combinación, se ejecutan otras pruebas de aceptación que tardan más

tiempo en completarse. Estas pruebas tradicionales posteriores a la comprobación
realizan una validación más exhaustiva. Este proceso de pruebas proporciona un buen
equilibrio entre tener pruebas rápidas durante la revisión de la solicitud de
incorporación de cambios y tener una cobertura de prueba completa antes del
lanzamiento de la versión.

Diferencias con GitHub Flow

El flujo de GitHub es un popular flujo de versiones de desarrollo troncal que
permite a las organizaciones implementar un enfoque escalable para Git. Sin embargo,
algunas organizaciones encuentran que, a medida que sus necesidades crecen, deben
diferir de partes del flujo de GitHub.
Por ejemplo, una parte que se suele pasar por alto del flujo de GitHub es que las
solicitudes de incorporación de cambios deben implementarse en producción para
realizar pruebas antes de poder combinarlas con la rama principal. Este proceso significa
que todas las solicitudes de incorporación de cambios esperan en la cola de
implementación para combinarse.

Algunos equipos tienen varios cientos de desarrolladores trabajando constantemente en

un único repositorio, los cuales pueden completar más de 200 solicitudes de
incorporación de cambios en la rama principal al día. Si cada solicitud de incorporación
de cambios requiere una implementación en varios centros de datos de Azure en todo
el mundo para realizar pruebas, los desarrolladores dedican tiempo a esperar a que las
ramas se combinen, en lugar de escribir software.

En cambio, los equipos de Microsoft siguen desarrollando en la rama principal y

procesan por lotes las implementaciones en lanzamientos con hora, normalmente
alineadas con una cadencia de sprint de tres semanas.

Detalles de la implementación
Estos son algunos detalles clave de implementación del flujo de versiones de Microsoft:

Estrategia del repositorio de Git

Los distintos equipos tienen estrategias diferentes para administrar sus repositorios de
Git. Algunos equipos mantienen la mayoría de su código en un repositorio de Git. El
código se divide en componentes, cada uno de ellos en su propia carpeta de nivel raíz.
Los componentes grandes, especialmente los componentes más antiguos, pueden tener
varios subcomponentes que tienen subcarpetas independientes dentro del componente
primario.
Repositorios adjuntos
Algunos equipos también administran repositorios adjuntos. Por ejemplo, los agentes
y las tareas de compilación y versión, la extensión de VS Code y los proyectos de
código abierto se desarrollan en GitHub. Los cambios de configuración se activan en
un repositorio independiente. Otros paquetes de los que depende el equipo proceden
de otros lugares y se consumen a través de NuGet.

Repositorio mono o múltiple

Aunque algunos equipos eligen tener un único repositorio monolítico, un repositorio

mono, otros productos de Microsoft usan un enfoque de repositorio múltiple. Skype, por
ejemplo, tiene cientos de repositorios pequeños que se unen en varias combinaciones
para crear muchos clientes, servicios y herramientas diferentes. Especialmente para los
equipos que adoptan microservicios, los repositorios múltiples pueden ser el enfoque
adecuado. Normalmente, los productos más antiguos que comenzaron como monolitos
encuentran un enfoque de repositorio mono para ser la transición más sencilla a Git, y
su organización de código lo refleja.
Ramas de versión
El flujo de versiones de Microsoft permite que la rama principal admita la compilación
en todo momento. Los desarrolladores trabajan en ramas puntuales de corta duración
que se combinan con main . Cuando un equipo está listo para enviarse, ya sea al final de
un sprint o para una actualización importante, inicia una nueva rama de versión a partir
de la rama principal. Las ramas de versión nunca se combinan con la rama principal, por
lo que pueden requerir la selección exclusiva de cambios importantes.

En el diagrama siguiente se muestran ramas de corta duración en azul y ramas de

versión en negro. Hay una rama con una confirmación que necesita la selección
exclusiva que aparece en rojo.

Directivas y permisos de rama

Las directivas de rama de Git ayudan a aplicar la estructura de las ramas de versión y
mantienen la rama principal limpia. Por ejemplo, las directivas de rama pueden impedir
inserciones directas en la rama principal.

Para mantener ordenada la jerarquía de ramas, los equipos usan permisos para bloquear
la creación de ramas en el nivel raíz de la jerarquía. En el ejemplo siguiente, todos los
usuarios pueden crear ramas en carpetas como usuarios/, características/ y equipos/.
Solo los administradores de versiones tienen permiso para crear ramas en versiones/, y
algunas herramientas de automatización tienen permiso para la carpeta integraciones/.
Flujo de trabajo del repositorio de Git
Dentro del repositorio y la estructura de rama, los desarrolladores realizan su trabajo
diario. Los entornos de trabajo varían en gran medida según el equipo y el individuo.
Algunos desarrolladores prefieren la línea de comandos, otros como Visual Studio y
otros funcionan en distintas plataformas. Las estructuras y directivas en vigor en los
repositorios de Microsoft aseguran una base sólida y coherente.

Un flujo de trabajo típico implica las siguientes tareas comunes:

Creación de una nueva característica

La creación de una nueva característica es el núcleo del trabajo de un desarrollador de
software. Entre las partes del proceso que no son de Git se incluyen el análisis de los
datos de telemetría, la creación de un diseño y una especificación, y la escritura del
código real. A continuación, el desarrollador comienza a trabajar con el repositorio
mediante la sincronización con la confirmación más reciente en main . La rama principal
siempre admite la compilación, por lo que se garantiza que sea un buen punto de
partida. El desarrollador extrae una nueva rama de características, realiza cambios de
código, confirmaciones e inserciones en el servidor e inicia una nueva solicitud de
incorporación de cambios.

Uso de directivas y comprobaciones de rama

Tras la creación de una solicitud de incorporación de cambios, los sistemas
automatizados comprueban que el nuevo código se compila, no interrumpe nada y no
infringe ninguna directiva de seguridad o cumplimiento. Este proceso no impide que se
produzca otro trabajo en paralelo.
Las directivas y comprobaciones de rama pueden requerir una compilación correcta,
incluidas las pruebas superadas, la aprobación de los propietarios de cualquier código
alterado y varias comprobaciones externas para verificar las directivas corporativas antes
de que se pueda completar una solicitud de incorporación de cambios.

Integrar con Microsoft Teams

Muchos equipos configuran la integración con Microsoft Teams , que anuncia la nueva
solicitud de incorporación de cambios a los compañeros de equipo de los
desarrolladores. Los propietarios de cualquier código alterado se agregan
automáticamente como revisores. Los equipos de Microsoft suelen usar revisores
opcionales para el código que muchas personas alteran, como la generación de clientes
REST y los controles compartidos, para tener ojos expertos sobre esos cambios.
Implementación con marcas de características
Una vez satisfechos los revisores y los propietarios del código y la automatización se ha
realizado correctamente, el desarrollador puede completar la solicitud de incorporación
de cambios. Si hay un conflicto de combinación, el desarrollador obtiene instrucciones
sobre cómo sincronizar con el conflicto, corregirlo y volver a insertar los cambios. La
automatización se ejecuta de nuevo en el código corregido, pero las personas no tienen
que aprobarlo de nuevo.

La rama se combina con main y el nuevo código se implementa en el siguiente sprint o

versión principal. Esto no significa que la nueva característica se muestre
inmediatamente. Microsoft desacopla la implementación y exposición de nuevas
características mediante marcas de características.

Incluso si la característica necesita un poco más de trabajo antes de que esté lista para
mostrarse, es seguro ir a main si el producto compila e implementa. Una vez en main , el
código pasa a formar parte de una compilación oficial, donde se vuelve a probar,
confirmar que cumple la directiva y firmar digitalmente.
Desplazamiento a la izquierda para detectar problemas
pronto
Este flujo de trabajo de Git proporciona varias ventajas. En primer lugar, el
funcionamiento de una sola rama principal prácticamente elimina la deuda de
combinación . En segundo lugar, el flujo de solicitud de incorporación de cambios
proporciona un punto común para aplicar pruebas, revisión de código y detección de
errores de forma temprana en la canalización. Esta estrategia de desplazamiento a la
izquierda ayuda a acortar el ciclo de comentarios a los desarrolladores porque puede
detectar errores en minutos, en vez de horas o días. Esta estrategia también proporciona
confianza para la refactorización, ya que todos los cambios se prueban constantemente.

Actualmente, un producto con más de 200 solicitudes de incorporación de cambios

podría producir más de 300 compilaciones de integración continuas al día, lo que
equivale a más de 500 ejecuciones de pruebas cada 24 horas. Este nivel de prueba sería
imposible sin el flujo de trabajo de ramificación y versión troncal.

Lanzamiento en hitos de sprint

Al final de cada sprint, el equipo crea una rama de versión a partir de la rama principal.
Por ejemplo, al final del sprint 129, el equipo crea una nueva rama de versión
releases/M129 . A continuación, el equipo coloca la rama sprint 129 en producción.

Después de la rama de la rama de versión, la rama principal permanece abierta para que
los desarrolladores combinen los cambios. Estos cambios se implementarán tres
semanas más tarde en la siguiente implementación de sprint.

Revisiones de la versión
A veces, los cambios deben ir a producción rápidamente. Microsoft no suele agregar
nuevas características en medio de un sprint, pero a veces quiere traer una corrección
de errores rápidamente para desbloquear a los usuarios. Los problemas pueden ser
menores, como errores tipográficos, o lo suficientemente grandes como para provocar
un problema de disponibilidad o un incidente de sitio activo.

La rectificación de estos problemas comienza con el flujo de trabajo normal. Un

desarrollador crea una rama a partir de main , obtiene el código revisado y completa la
solicitud de incorporación de cambios para combinarla. El proceso siempre comienza
realizando el cambio en main primero. Esto permite crear la corrección rápidamente y
validarla localmente sin tener que cambiar a la rama de versión.

Al seguir este proceso también se garantiza que el cambio se aplica en main , lo cual es
fundamental. Corregir un error en la rama de versión sin devolver el cambio a main
significaría que el error se repetiría durante la siguiente implementación, cuando la
versión del sprint 130 se ramifica a partir de main . Es fácil olvidarse de actualizar main
durante la confusión y el estrés que pueden surgir durante una interrupción. La
incorporación de cambios en main en primer lugar significa tener siempre los cambios
en la rama principal y en la rama de versión.

La funcionalidad de Git habilita este flujo de trabajo. Para incorporar los cambios
inmediatamente en producción, una vez que un desarrollador combina una solicitud de
incorporación de cambios con main , puede usar la página de solicitud de incorporación
de cambios para seleccionar los cambios en la rama de versión. Este proceso crea una
nueva solicitud de incorporación de cambios que tiene como destino la rama de versión
y devuelve el contenido que se acaba de combinar con main .

El uso de la funcionalidad de selección exclusiva abre rápidamente una solicitud de

incorporación de cambios, lo que proporciona la rastreabilidad y confiabilidad de las
directivas de rama. La selección exclusiva puede producirse en el servidor, sin tener que
descargar la rama de versión en un equipo local. Realizar cambios, corregir conflictos de
combinación o realizar cambios menores debido a las diferencias entre las dos ramas
son cosas que pueden ocurrir en el servidor. Los equipos pueden editar los cambios
directamente desde el editor de texto basado en explorador o a través de la Extensión
de conflicto de combinación de solicitud de incorporación de cambios para obtener
una experiencia más avanzada.

Una vez que una solicitud de incorporación de cambios tiene como destino la rama de
versión, el código del equipo la revisa de nuevo, evalúa las directivas de rama, prueba la
solicitud de incorporación de cambios y la combina. Después de la combinación, la
corrección se implementa en el primer anillo de servidores en minutos. Desde allí, el
equipo implementa progresivamente la corrección en más cuentas mediante anillos de
implementación. A medida que los cambios se implementan en más usuarios, el equipo
supervisa el éxito y comprueba que el cambio corrige el error sin introducir deficiencias
ni ralentizaciones. La corrección finalmente se implementa en todos los centros de datos
de Azure.

Pasar al siguiente sprint

Durante las tres semanas siguientes, el equipo termina de agregar características al
sprint 130 y está listo para implementar esos cambios. Crean la nueva rama de versión,
releases/M130 a partir de main , y la implementan.

En este momento, de hecho hay dos ramas en producción. Con una implementación
basada en anillos para llevar los cambios a producción de forma segura, el anillo
anticipado obtiene los cambios del sprint 130 y los servidores del anillo lento
permanecen en el sprint 129 mientras los nuevos cambios se validan en producción.

La revisión de un cambio en medio de una implementación podría requerir la revisión

de dos versiones diferentes, la versión del sprint 129 y la versión del sprint 130. El
equipo conecta al puerto e implementa la revisión en ambas ramas de versión. La rama
130 se vuelve a implementar con la revisión en los anillos que ya se han actualizado. La
rama 129 se vuelve a implementar con la revisión en los anillos externos que aún no se
han actualizado a la versión del sprint siguiente.

Una vez implementados todos los anillos, se abandona la rama del sprint 129 anterior,
ya que los cambios introducidos en la rama del sprint 129 como revisión también se han
realizado en main . Por lo tanto, esos cambios también estarán en la rama
releases/M130 .

Resumen
El modelo de flujo de versión es la piedra angular de cómo Microsoft desarrolla con
DevOps para ofrecer servicios en línea. Este modelo usa una estrategia de ramificación
troncal sencilla. Sin embargo, en lugar de mantener a los desarrolladores bloqueados en
una cola de implementación, esperando para combinar sus cambios, el flujo de versión
de Microsoft les permite seguir trabajando.
Este modelo de versión también permite implementar nuevas características en centros
de datos de Azure a una cadencia regular, a pesar del tamaño de los código base de
Microsoft y del número de desarrolladores que trabajan en ellos. El modelo también
permite incorporar revisiones en producción de forma rápida y eficaz.
Introducción a la entrega de servicios de
calidad con DevOps
Artículo • 05/10/2023

En la fase de entrega de DevOps, el código pasa por la canalización de versión al

entorno de producción. La entrega de código suele aparecer después de la compilación
de integración continua y se ejecuta a través de varios entornos de prueba antes de
llegar a los usuarios finales. A lo largo del proceso, su calidad se prueba en muchas
medidas diferentes que incluyen funcionalidad, escala y seguridad.

Empleo de la entrega continua

La entrega continua (CD) es el proceso consistente en compilar, probar, configurar e
implementar automáticamente desde un entorno de compilación a uno de producción.
La CD proporciona la base para la entrega en DevOps en la que se ejecutan las pruebas,
se comprueban las puertas y se implementan los bits. Existen varias plataformas DevOps
que ofrecen automatización de entrega, incluidas GitHub Actions y Azure Pipelines .

Diseño para una implementación óptima

A medida que crecen, los proyectos de software pueden resultar difíciles de administrar
entre equipos, versiones y entornos. Afortunadamente, hay varios paradigmas
disponibles para ayudar a abordar estos desafíos. Un paradigma es la llegada de la
arquitectura de microservicios, que facilita la compilación e implementación de servicios
independientes que se pueden componer en aplicaciones más grandes y fáciles de
mantener. Otra práctica para ayudar en la implementación de servicios es administrar
los entornos de aplicación como infraestructura como código.

Desplazamiento a la derecha para ejecutar

pruebas en producción
En la fase de Desarrollo se muestra cómo se puede mejorar la calidad y la velocidad del
proyecto desplazando a la izquierda para que algunos aspectos de las pruebas se
realicen anteriormente en el proceso. De forma similar, la calidad del producto se puede
mejorar con un enfoque sostenido en el desplazamiento a la derecha a las pruebas en
producción. Las pruebas en producción ofrecen garantía de calidad que simplemente no
se pueden replicar en ningún otro lugar de la canalización.

Pasos siguientes
Microsoft ha sido una de las empresas de desarrollo de software más grandes del
mundo durante décadas. Descubra cómo Microsoft entrega en DevOps.

¿Busca una experiencia práctica de DevOps con entrega continua? Aprenda a configurar
canalizaciones de versión mediante Acciones de GitHub o Azure Pipelines.
¿Qué es la entrega continua?
Artículo • 05/10/2023

La entrega continua de valor se ha convertido en un requisito obligatorio para las

organizaciones. Para entregar valor a sus usuarios finales, debe realizar entregas
continuas y sin errores.

La entrega continua (CD) es el proceso consistente en automatizar la compilación, las

pruebas, la configuración y la implementación desde un entorno de compilación a uno
de producción. Una canalización de versión puede crear varios entornos de prueba o de
ensayo para automatizar la creación de la infraestructura e implementar nuevas
compilaciones. Los entornos sucesivos admiten actividades progresivamente más
prolongadas de integración, carga y pruebas de aceptación del usuario.

Antes de la CD, los ciclos de lanzamiento de software eran un cuello de botella para los
equipos de aplicaciones y operaciones. A menudo, estos equipos confiaban en entregas
manuales que provocaban problemas durante los ciclos de lanzamiento. Los procesos
manuales llevaban a versiones poco fiables que generaban retrasos y errores.

La CD es una práctica ajustada con el objetivo de mantener la producción actualizada

con la ruta más rápida desde la nueva disponibilidad de código o componente a la
implementación. La automatización minimiza el tiempo de implementación y el tiempo
para mitigar (TTM) o el tiempo para corregir (TTR) los incidentes de producción. En
términos lean, la CD optimiza el tiempo de proceso y elimina el tiempo de inactividad.

La integración continua (CI) inicia el proceso de CD. La canalización de versión almacena

provisionalmente cada entorno sucesivo en el siguiente entorno después de que las
pruebas se completen correctamente. La canalización de versión de CD automatizada
permite un enfoque de fracasar y responder rápido a los errores para la validación,
donde es más probable que las pruebas no se ejecuten rápidamente primero y las
pruebas de ejecución más largas solo se produzcan después de que las más rápidas se
completen correctamente.

Las prácticas complementarias de la infraestructura como código (IaC) y la supervisión

facilitan la CD.

Técnicas de exposición progresiva

La CD admite varios patrones para la exposición progresiva, también conocido como
"controlar el radio de explosión". Estas prácticas limitan la exposición a las
implementaciones para evitar problemas con la base de usuarios general.

La CD puede secuenciar varios anillos de implementación para la exposición

progresiva. Un anillo intenta realizar una implementación en un grupo de usuarios
y supervisa su experiencia. El primer anillo de implementación puede ser
controlado para probar nuevas versiones en producción antes de un lanzamiento
más amplio. La CD automatiza la implementación de un anillo al siguiente.

La implementación en el anillo siguiente puede depender opcionalmente de un

paso de aprobación manual, donde un responsable de la toma de decisiones
aprueba los cambios electrónicamente. La CD puede crear un registro auditable de
la aprobación para cumplir los procedimientos normativos u otros objetivos de
control.

La implementación azul/verde se basa en mantener activa una versión azul

existente mientras se implementa una nueva versión verde. Normalmente, esta
práctica usa el equilibrio de carga para aumentar directamente las cantidades de
tráfico para la implementación verde. Si la supervisión detecta un incidente, se
puede redirigir el tráfico a la implementación azul que sigue en ejecución.

Las marcas de características o la activación/desactivación de funcionalidad son

otra técnica que se usa para la experimentación y los inicios oscuros. Las marcas de
características activan o desactivan las características para diferentes grupos de
usuarios en función de su identidad y pertenencia a grupos.

Las canalizaciones de versión modernas permiten a los equipos de desarrollo

implementar nuevas características de forma rápida y segura. La CD puede corregir
rápidamente los problemas ocurridos en producción mediante la puesta al día con una
nueva implementación. De este modo, la CD crea un flujo continuo de valor de cliente.
Pasos siguientes
Acciones de GitHub
Azure Pipelines
Documentación de Azure Pipelines
¿Qué es la infraestructura como código
(IaC)?
Artículo • 05/10/2023

La infraestructura como código (IaC) usa la metodología de DevOps y el control de

versiones con un modelo descriptivo para definir e implementar la infraestructura, como
redes, máquinas virtuales, equilibradores de carga y topologías de conexión. Igual que
con el principio de que el mismo código fuente siempre genera el mismo archivo
binario, los modelos de IaC generan el mismo entorno cada vez que se aplican.

IaC es una práctica clave de DevOps y un componente de la entrega continua. Con IaC,
los equipos de DevOps pueden trabajar juntos con un conjunto unificado de prácticas y
herramientas para entregar aplicaciones y su infraestructura de soporte de forma rápida
y fiable a escala.

Evitar la configuración manual para aplicar

coherencia
IaC ha evolucionado para resolver el problema del desfase del entorno en las
canalizaciones de versión. Sin IaC, los equipos deben mantener la configuración del
entorno de implementación de forma individual. Con el tiempo, cada entorno se
convierte en un "copo de nieve", es decir, una configuración única que no se puede
reproducir automáticamente. La incoherencia entre entornos puede causar problemas
de implementación. La administración y el mantenimiento de la infraestructura implican
procesos manuales que son propensos a errores y difíciles de rastrear.
La IaC evita la configuración manual y aplica la coherencia mediante la representación
de estados de entorno deseados a través de código bien documentado en formatos
como JSON. Las implementaciones de infraestructura con IaC son repetibles y evitan
problemas en tiempo de ejecución causados por el desviado de configuración o
dependencias que faltan. Las canalizaciones de versión ejecutan las descripciones del
entorno y los modelos de configuración de versión para configurar entornos de destino.
Para realizar cambios, el equipo edita el origen, no el destino.

La idempotencia, la capacidad de una operación determinada para producir siempre el

mismo resultado, es un principio importante de IaC. Un comando de implementación
siempre establece el entorno de destino en la misma configuración,
independientemente del estado inicial del entorno. La idempotencia se logra
configurando automáticamente el destino existente o descartando el destino existente y
volviendo a crear un entorno nuevo.

Herramientas útiles
Detección de errores de configuración en IaC con Microsoft Defender for Cloud

Entrega de entornos de prueba estables

rápidamente a escala
IaC ayuda a los equipos de DevOps a probar aplicaciones en entornos similares al de
producción en una fase temprana del ciclo de desarrollo. Los equipos pueden
aprovisionar varios entornos de prueba de forma fiable y a petición. La nube aprovisiona
y reduce dinámicamente los entornos en función de las definiciones de IaC. El propio
código de infraestructura se puede validar y probar para evitar problemas comunes de
implementación.

Uso de archivos de definición declarativos

La IaC debe usar archivos de definición declarativos si es posible. Un archivo de
definición describe los componentes y la configuración que requiere un entorno, pero
no necesariamente cómo lograr esa configuración. Por ejemplo, el archivo podría definir
una versión y una configuración de servidor necesarias, pero no especificar el proceso
de instalación y configuración del servidor. Esta abstracción permite una mayor
flexibilidad para usar técnicas optimizadas que proporciona el proveedor de la
infraestructura. Las definiciones declarativas también ayudan a reducir la deuda técnica
de mantener código imperativo, como los scripts de implementación, que puede
acumularse con el tiempo.
No hay ninguna sintaxis estándar para la IaC declarativa. La sintaxis para describir la IaC
normalmente depende de los requisitos de la plataforma de destino. Las distintas
plataformas admiten formatos de archivo como YAML, JSON y XML.

Implementación de IaC en Azure

Azure proporciona compatibilidad nativa con IaC a través del modelo de Azure Resource
Manager. Los equipos pueden definir plantillas ARM declarativas que especifiquen la
infraestructura necesaria para implementar las soluciones.

Las plataformas de terceros como Terraform, Ansible, Chef y Pulumi también admiten
la IaC para administrar la infraestructura automatizada.
Realizar implementaciones en
infraestructura de Azure con Acciones
de GitHub
Artículo • 05/10/2023

En esta guía, trataremos cómo usar CI/CD e infraestructura como código (IaC) para
implementar en Azure con Acciones de GitHub de forma automatizada y repetible.

Este artículo es una introducción a la arquitectura y presenta una solución estructurada

para diseñar una aplicación en Azure que es escalable, segura, resistente y de alta
disponibilidad. Para ver ejemplos más reales de arquitecturas en la nube e ideas de
soluciones, examine las arquitecturas de Azure.

Ventajas del uso de IaC y automatización para

las implementaciones
Hay muchas maneras de implementar en Azure, como Azure Portal, CLI, API y muchas
más. Para esta guía, usaremos IaC y automatización de CI/CD. Las ventajas de este
enfoque incluyen:

Declarativo: al definir el proceso de implementación e infraestructura en el código,

se puede versionar y revisar mediante el ciclo de vida de desarrollo de software
estándar. IaC también ayuda a evitar cualquier desfase en la configuración.

Coherencia: el seguimiento de un proceso de IaC garantiza que toda la

organización siga un método estándar y bien establecido para implementar la
infraestructura que incorpore procedimientos recomendados y se proteja para
satisfacer sus necesidades de seguridad. Las mejoras realizadas en las plantillas
centrales se pueden aplicar fácilmente en toda la organización.

Seguridad: las plantillas administradas centralmente se pueden proteger y aprobar

mediante un equipo de operaciones o seguridad en la nube para cumplir los
estándares internos.

Autoservicio: se puede capacitar a los equipos para implementar sus propias

infraestructuras mediante el uso de plantillas administradas centralmente.

Productividad mejorada: mediante el uso de plantillas estándar, los equipos

pueden aprovisionar rápidamente nuevos entornos sin necesidad de preocuparse
por todos los detalles de la implementación.
Puede encontrar información adicional en infraestructura repetible en el Centro de
arquitectura de Azure o en qué es la infraestructura como código en el Centro de
recursos de DevOps.

Architecture

Flujo de datos
1. Cree una nueva rama y compruebe las modificaciones de código IaC necesarias.
2. Cree una solicitud de incorporación de cambios (PR) en GitHub una vez que esté
preparado para combinar los cambios en su entorno.
3. Se desencadenará un flujo de trabajo de Acciones de GitHub para asegurar que el
código tiene un formato correcto, es coherente internamente y genera una
infraestructura segura. Además, se ejecutará un análisis de hipótesis de Terraform o
Bicep para generar una vista previa de los cambios que se producirán en el
entorno de Azure.
4. Una vez revisada correctamente, la solicitud de incorporación de cambios se puede
combinar en la rama principal.
5. Otro flujo de trabajo de Acciones de GitHub se desencadenará desde la rama
principal y ejecutará los cambios mediante el proveedor de IaC.
6. (exclusivo de Terraform) También debe ejecutarse un flujo de trabajo de Acción de
GitHub programado periódicamente para buscar cualquier desfase de
configuración en el entorno y crear un problema nuevo si se detectan cambios.

Requisitos previos

Uso de Bicep
1. Creación de entornos de GitHub

Los flujos de trabajo usan entornos y secretos de GitHub para almacenar la

información de identidad de Azure y configurar un proceso de aprobación para las
implementaciones. Cree un entorno denominado production siguiendo estas
instrucciones . En el entorno production , configure una regla de protección y
agregue los aprobadores necesarios que desee que tengan que aprobar las
implementaciones de producción. También puede limitar el entorno a la rama
principal. Aquí puede encontrar instrucciones detalladas.

2. Configuración de la identidad de Azure:

Se requiere una aplicación de Azure Active Directory que tenga permisos para
implementar dentro de la suscripción de Azure. Cree una sola aplicación y asígnele
los permisos de lectura y escritura adecuados en la suscripción de Azure. A
continuación, configure las credenciales federadas para permitir que GitHub use la
identidad mediante OpenID Connect (OIDC). Para obtener instrucciones detalladas,
consulte la Documentación de Azure. Es necesario agregar tres credenciales
federadas:

Establezca el Tipo de entidad en Environment y use el nombre de entorno

production .

Establezca Tipo de entidad en Pull Request .

Establezca Tipo de entidad en Branch y use el nombre de rama main .

3. Agregar secretos de GitHub

７ Nota

Aunque ninguno de los datos sobre las identidades de Azure contiene

secretos o credenciales, todavía usamos los secretos de GitHub como un
medio práctico para parametrizar la información de identidad por entorno.

Cree los siguientes secretos en el repositorio mediante la identidad de Azure:

AZURE_CLIENT_ID : identificador de la aplicación (cliente) del registro de la

aplicación en Azure
AZURE_TENANT_ID : identificador de inquilino de Azure Active Directory donde

se define el registro de la aplicación.

AZURE_SUBSCRIPTION_ID : identificador de suscripción donde se define el

registro de la aplicación.
 Aquí puede encontrar instrucciones para agregar los secretos al repositorio.

Uso de Terraform
1. Configuración de la ubicación de estado de Terraform

Terraform utiliza un archivo de estado para almacenar información sobre el

estado actual de la infraestructura administrada y la configuración asociada. Este
archivo deberá conservarse entre distintas ejecuciones del flujo de trabajo. El
enfoque recomendado es almacenar este archivo dentro de una cuenta de Azure
Storage u otro back-end remoto similar. Normalmente, este almacenamiento se
aprovisionaría manualmente o a través de un flujo de trabajo independiente. El
bloque back-end de Terraform necesitará actualizarse con la ubicación de
almacenamiento seleccionada (consulte aquí la documentación).

2. Creación del entorno de GitHub

Los flujos de trabajo usan entornos y secretos de GitHub para almacenar la

información de identidad de Azure y configurar un proceso de aprobación para las
implementaciones. Cree un entorno denominado production siguiendo estas
instrucciones . En el entorno production , configure una regla de protección y
agregue los aprobadores necesarios que desee que tengan que aprobar las
implementaciones de producción. También puede limitar el entorno a la rama
principal. Aquí puede encontrar instrucciones detalladas.

3. Configuración de la identidad de Azure:

Se requiere una aplicación de Azure Active Directory que tenga permisos para
implementar dentro de la suscripción de Azure. Cree una aplicación independiente
para read-only y read/write cuentas y asígneles los permisos adecuados en la
suscripción de Azure. Además, ambos roles también necesitarán al menos Reader
and Data Access permisos para la cuenta de almacenamiento donde reside el

estado de Terraform del paso 1. A continuación, configure las credenciales

federadas para permitir que GitHub use la identidad mediante OpenID Connect
(OIDC). Para obtener instrucciones detalladas, consulte la Documentación de
Azure.

Para la identidad read/write , cree una credencial federada de la siguiente manera:

Establezca Entity Type en Environment y use el nombre de entorno

production .
 Para la identidad read-only , cree dos credenciales federadas de la siguiente
manera:

Establezca Entity Type en Pull Request .

Establezca Entity Type en Branch y use el nombre de rama main .

4. Agregar secretos de GitHub

７ Nota

Aunque ninguno de los datos sobre las identidades de Azure contiene

secretos o credenciales, todavía usamos los secretos de GitHub como un
medio práctico para parametrizar la información de identidad por entorno.

Cree los siguientes secretos en el repositorio mediante la identidad read-only :

AZURE_CLIENT_ID : identificador de la aplicación (cliente) del registro de la

aplicación en Azure
AZURE_TENANT_ID : identificador de inquilino de Azure Active Directory donde

se define el registro de la aplicación.

AZURE_SUBSCRIPTION_ID : identificador de suscripción donde se define el

registro de la aplicación.

Aquí puede encontrar instrucciones para agregar los secretos al repositorio.

Cree otro secreto en el entorno production utilizando la identidad read-write :

AZURE_CLIENT_ID : identificador de la aplicación (cliente) del registro de la

aplicación en Azure

Aquí puede encontrar instrucciones para agregar los secretos al entorno. El

secreto de entorno invalidará el secreto del repositorio al realizar el paso de
implementación en el entorno production cuando se requieran permisos elevados
de lectura y escritura.

Implementación con acciones de GitHub

Uso de Bicep
La arquitectura de referencia incluye dos flujos de trabajo principales:

1. Pruebas unitarias de Bicep

 Este flujo de trabajo se ejecuta en cada confirmación y se compone de un conjunto
de pruebas unitarias en el código de infraestructura. Ejecuta la compilación de
bicep para compilar el bicep en una plantilla de ARM. Esto garantiza que no haya
errores de formato. A continuación, realiza una validación para asegurar que la
plantilla se puede implementar. Por último, se ejecutará checkov , una
herramienta de análisis de código estático de código abierto para IaC, para
detectar problemas de seguridad y cumplimiento. Si el repositorio usa GitHub
Advanced Security (GHAS), los resultados se cargarán en GitHub.

2. Bicep What-If / Deploy

Este flujo de trabajo se ejecuta en cada solicitud de incorporación de cambios y en

cada confirmación en la rama principal. La fase what-if del flujo de trabajo se usa
para comprender el impacto de los cambios de IaC en el entorno de Azure
mediante la ejecución de what-if. Este informe se adjunta entonces a la solicitud de
incorporación de cambios para facilitar la revisión. La fase de implementación se
ejecuta después del análisis de hipótesis cuando se desencadena el flujo de trabajo
mediante una inserción en la rama principal. Esta fase implementará la plantilla en
Azure después de que se haya aprobado una revisión manual.

Uso de Terraform
La arquitectura de referencia incluye tres flujos de trabajo principales:

1. Pruebas unitarias de Terraform

Este flujo de trabajo se ejecuta en cada confirmación y se compone de un conjunto

de pruebas unitarias en el código de infraestructura. Ejecuta terraform fmt para
asegurar que el linting del código se ha realizado correctamente y que sigue los
procedimientos recomendados de terraform. A continuación, realiza la validación
de terraform para comprobar que el código es sintácticamente correcto e
internamente coherente. Por último, se ejecutará checkov , una herramienta de
análisis de código estático de código abierto para IaC, para detectar problemas de
seguridad y cumplimiento. Si el repositorio usa GitHub Advanced Security (GHAS),
los resultados se cargarán en GitHub.

2. Terraform Plan / Apply

Este flujo de trabajo se ejecuta en cada solicitud de incorporación de cambios y en

cada confirmación en la rama principal. La fase plan del flujo de trabajo se usa para
comprender el impacto de los cambios de IaC en el entorno de Azure mediante la
ejecución de terraform plan . Este informe se adjunta entonces a la solicitud de
incorporación de cambios para facilitar la revisión. La fase de aplicación se ejecuta
 después del plan cuando el flujo de trabajo se desencadena mediante una
inserción en la rama principal. Esta fase tomará el documento del plan y aplicará
los cambios después de que se haya aprobado una revisión manual si hay cambios
pendientes en el entorno.

3. Terraform Drift Detection

Este flujo de trabajo se ejecuta periódicamente para examinar el entorno en busca

de cualquier desfase de configuración o cambios realizados fuera de Terraform. Si
se detecta algún desfase, se genera un problema de GitHub para alertar a los
mantenedores del proyecto.

Recursos relacionados
¿Qué es la infraestructura como código?
Infraestructura repetible
Comparación de Terraform y Bicep
Checkov y código fuente
Seguridad avanzada de GitHub
¿Qué son los microservicios?
Artículo • 05/10/2023

Los microservicios describen el proceso arquitectónico de crear una aplicación

distribuida a partir de servicios que se pueden implementar por separado y que realizan
funciones empresariales específicas y se comunican a través de interfaces web. Los
equipos de DevOps engloban partes individuales de la funcionalidad en microservicios y
crean sistemas más grandes mediante la combinación de microservicios como bloques
de creación.

Los microservicios aplican un ejemplo del principio abierto/cerrado:

Están abiertos para la extensión (mediante las interfaces que exponen)

Están cerrados para la modificación (cada uno se implementa y se versiona de
forma independiente)

Los microservicios proporcionan numerosas ventajas frente a las arquitecturas

monolíticas:

Pueden quitar puntos únicos de error (SPOF) asegurándose de que los problemas
de un servicio no se bloquean ni afectan a otras partes de una aplicación.
Los microservicios individuales se pueden escalar horizontalmente de forma
independiente para proporcionar disponibilidad y capacidad adicionales.
Los equipos de DevOps pueden ampliar la funcionalidad agregando nuevos
microservicios sin afectar innecesariamente a otras partes de la aplicación.

El uso de microservicios puede aumentar la velocidad del equipo. Las prácticas de

DevOps, como la integración continua y la entrega continua, se usan para impulsar las
implementaciones de microservicios. Los microservicios complementan perfectamente
las arquitecturas de aplicaciones basadas en la nube al permitir que los equipos de
desarrollo de software aprovechen escenarios como la programación controlada por
eventos y la escalabilidad automática. Los componentes de microservicio exponen las
API (interfaces de programación de aplicaciones), normalmente a través de protocolos
REST, para comunicarse con otros servicios.

Una práctica cada vez más común es usar clústeres de contenedores para implementar
microservicios. Los contenedores permiten el aislamiento, el empaquetado y la
implementación de microservicios, mientras que la orquestación escala horizontalmente
un grupo de contenedores en una aplicación.

Pasos siguientes
Obtenga más información sobre los microservicios en Azure .
Desplazamiento a la derecha para
ejecutar pruebas en producción
Artículo • 05/10/2023

Desplazamiento a la derecha es la práctica de mover algunas pruebas más adelante en

el proceso de DevOps para probar en producción. Las pruebas en producción usan
implementaciones reales para validar y medir el comportamiento y el rendimiento de
una aplicación en el entorno de producción.

Una manera en que los equipos de DevOps pueden mejorar la velocidad es con una
estrategia de prueba de desplazamiento a la izquierda. El desplazamiento a la izquierda
inserta la mayoría de las pruebas anteriormente en la canalización de DevOps, para
reducir la cantidad de tiempo para que el código nuevo llegue a producción y funcione
de forma confiable.

Pero aunque muchos tipos de pruebas, como las pruebas unitarias, pueden desplazarse
fácilmente a la izquierda, algunas clases de pruebas no se pueden ejecutar sin
implementar toda una solución o parte de ella. La implementación en un servicio de
control de calidad o almacenamiento provisional puede simular un entorno comparable,
pero no hay ningún sustituto completo del entorno de producción. Los equipos
encuentran que determinados tipos de pruebas deben producirse en producción.

Las pruebas en producción proporcionan:

La amplitud y diversidad del entorno de producción.

La carga de trabajo real del tráfico del cliente.
Perfiles y comportamientos según evoluciona la demanda de producción con el
tiempo.

El entorno de producción sigue cambiando. Aunque una aplicación no cambie, la

infraestructura en que se basa cambia constantemente. Las pruebas en producción
validan el estado y la calidad de una implementación de producción determinada y del
entorno de producción en constante cambio.

El desplazamiento a la derecha a las pruebas en producción es especialmente

importante para los escenarios siguientes:

Implementaciones de microservicios
Las soluciones basadas en microservicios pueden tener un gran número de
microservicios desarrollados, implementados y administrados de forma independiente.
El desplazamiento de pruebas a la derecha es especialmente importante para estos
proyectos, ya que las diferentes versiones y configuraciones pueden llegar a producción
de muchas maneras. Independientemente de la cobertura de pruebas de preproducción,
es necesario probar la compatibilidad en producción.

Garantizar la calidad posterior a la implementación

La liberación a producción es solo la mitad de la entrega de un software. La otra mitad
es garantizar la calidad a escala con una carga de trabajo real en producción. Dado que
el entorno sigue cambiando, un equipo nunca termina las pruebas en producción.

Los datos de prueba de producción son literalmente los resultados de la prueba de la

carga de trabajo del cliente real. Las pruebas en producción incluyen la supervisión, las
pruebas de conmutación por error y la inyección de errores. Esta prueba realiza un
seguimiento de errores, excepciones, métricas de rendimiento y eventos de seguridad.
La telemetría de prueba también ayuda a detectar anomalías.

Anillos de implementación
Para proteger el entorno de producción, los equipos pueden implementar cambios de
forma progresiva y controlada mediante implementaciones basadas en anillos y marcas
de características. Por ejemplo, es mejor detectar un error que impida que un
comprador complete su compra cuando menos del 1 % de los clientes están en ese
anillo de implementación que cambiar después a todos los clientes a la vez. El valor de
la característica con errores detectados debe superar las pérdidas netas de esos errores,
medida de forma significativa para la empresa en cuestión.

El primer anillo debe ser el tamaño más pequeño necesario para ejecutar el conjunto de
integración estándar. Las pruebas pueden ser similares a las que ya se ejecutaron
anteriormente en la canalización en otros entornos, pero las pruebas validan que el
comportamiento es el mismo en el entorno de producción. Este anillo identifica errores
obvios, como configuraciones incorrectas, antes de que afecten a los clientes.

Una vez validado el anillo inicial, el siguiente anillo puede ampliarse para incluir un
subconjunto de usuarios reales para la ejecución de pruebas. Si todo se ve bien, la
implementación puede avanzar a través de más anillos y pruebas hasta que todos los
usuarios lo usen. La implementación completa no significa que hayan terminado las
pruebas. El seguimiento de la telemetría es fundamental para las pruebas en
producción.
Inyección de errores
Los equipos suelen emplear la inserción de errores y la ingeniería de caos para ver cómo
se comporta un sistema en condiciones de error. Estas prácticas ayudan a:

Validar que los mecanismos de resistencia implementados funcionan realmente.

Comprobar que un error de un subsistema está contenido en ese subsistema y no
se traslada en cascada para producir una interrupción importante.
Demostrar que el trabajo de reparación de un incidente anterior tiene el efecto
deseado, sin tener que esperar a que se produzca otro incidente.
Crear simulacros de entrenamiento más realistas para los ingenieros de sitio
activos, para que puedan prepararse mejor para tratar los incidentes.

Se recomienda automatizar los experimentos de inyección de errores, ya que son

pruebas costosas que deben ejecutarse en los sistemas que cambian constantemente.

La ingeniería de caos puede ser una herramienta eficaz, pero debe limitarse a
entornos controlados que tienen poco o ningún impacto en el cliente.

Pruebas de conmutación por error

Una forma de inyección de errores es la prueba de conmutación por error para apoyar la
continuidad empresarial y la recuperación ante desastres (BCDR). Los equipos deben
tener planes de conmutación por error para todos los servicios y subsistemas. Los
planes deben incluir:

Una explicación clara del impacto empresarial de la interrupción del servicio.

Un mapa de todas las dependencias en términos de plataforma, tecnología y
personas que elaboran los planes BCDR.
Documentación formal de los procedimientos de recuperación ante desastres.
Una cadencia para ejecutar periódicamente simulacros de recuperación ante
desastres.

Pruebas de errores de disyuntor

Un mecanismo de disyuntor corta un componente determinado de un sistema más
grande, normalmente para evitar que los errores de ese componente se extiendan fuera
de sus límites. Puede activar intencionadamente los disyuntores para probar los
escenarios siguientes:

Si un dispositivo de reserva funciona cuando se activa el disyuntor. El dispositivo

de reserva podría funcionar con pruebas unitarias, pero la única manera de saber si
 se comportará según lo previsto en producción es insertar un error para
desencadenarlo.

Si el disyuntor tiene el umbral de sensibilidad adecuado para abrirse cuando sea

necesario. La inserción de errores puede forzar la latencia o desconectar las
dependencias para observar la capacidad de respuesta del disyuntor. Es
importante comprobar no solo que se produzca el comportamiento correcto, sino
que suceda lo suficientemente rápido.

Ejemplo: Prueba de un disyuntor de caché de Redis

Redis Cache mejora el rendimiento del producto al acelerar el acceso a los datos
usados habitualmente. Considere un escenario que tome una dependencia no crítica en
Redis. Si Redis deja de funcionar, el sistema debe seguir funcionando, ya que puede
revertir al uso del origen de datos original para las solicitudes. Para confirmar que un
error de Redis desencadena un disyuntor y que la reserva funciona en producción,
ejecute periódicamente pruebas con estos comportamientos.

En el diagrama siguiente se muestran las pruebas para el comportamiento de reserva

del disyuntor de Redis. El objetivo es asegurarse de que cuando se abra el separador, las
llamadas en última instancia irán a SQL.

En el diagrama anterior se muestran tres AT, con los disyuntores delante de las llamadas
a Redis. Una prueba obliga al disyuntor a abrirse a través de un cambio de configuración
y, a continuación, observa si las llamadas van a SQL. A continuación, otra prueba
comprueba el cambio de configuración opuesto, cerrando el disyuntor para confirmar
que las llamadas vuelven a Redis.
Esta prueba valida que el comportamiento de reserva funciona cuando se abre el
disyuntor, pero no valida que la configuración del disyuntor abra el disyuntor cuando
debería. La prueba de ese comportamiento requiere simular errores reales.

Un agente defectuoso puede introducir errores en las llamadas que van a Redis. En el
diagrama siguiente se muestran las pruebas con inyección de errores.

1. El inyector de errores bloquea las solicitudes de Redis.

2. Se abre el disyuntor y la prueba puede observar si funciona la reserva.
3. El error se quita y el disyuntor envía una solicitud de prueba a Redis.
4. Si la solicitud se realiza correctamente, las llamadas vuelven a Redis.

Otros pasos podrían probar la sensibilidad del separador, si el umbral es demasiado alto
o demasiado bajo, y si otros tiempos de espera del sistema interfieren con el
comportamiento del disyuntor.

En este ejemplo, si el disyuntor no se abre o se cierra según lo previsto, podría provocar

un incidente de sitio activo (LSI). Sin las pruebas de inyección de errores, es posible que
el problema no se detecte, ya que es difícil realizar este tipo de pruebas en un entorno
de laboratorio.

Pasos siguientes
[Desplazamiento de prueba a la izquierda con pruebas unitarias]shift-left
¿Qué son los microservicios?
Ejecución de una recuperación ante desastres de prueba (simulacro de
recuperación ante desastres) en Azure
Procedimientos de implementación seguros
¿Qué es la supervisión?
Cómo distribuye Microsoft el software
con DevOps
Artículo • 05/10/2023

Microsoft tiene décadas de experiencia entregando servicios altamente escalables a

entornos de producción. A medida que los servicios y entornos de Microsoft se han
ampliado, sus prácticas de entrega también han ido evolucionado. Muchos clientes de
Microsoft también han adoptado y se benefician de estas prácticas de entrega
eficientes. Los siguientes principios y procesos básicos de DevOps se pueden aplicar a
cualquier esfuerzo moderno de entrega de software.

Para implementar procesos de entrega de DevOps, Microsoft adoptó las siguientes

iniciativas:

Centrar la mentalidad y la cadencia de la organización en la entrega.

Formar equipos autónomos y responsables que posean, prueben y entreguen
características.
Desplazar a la derecha para probar y supervisar los sistemas en producción.

Centrarse en la entrega
El envío más rápido es una ventaja obvia que las organizaciones y los equipos pueden
medir y apreciar fácilmente. La cadencia típica de DevOps implica ciclos de sprint cortos
con implementaciones regulares en producción.

Temiendo la falta de estabilidad del producto con sprints cortos, algunos equipos lo
habían compensado con períodos de estabilización al final de los ciclos de sprint. Los
ingenieros querían enviar tantas características como fuera posible durante el sprint, por
lo que incurrían en una deuda de pruebas que terminaban pagando durante la
estabilización. Los equipos que administraban su deuda durante el sprint tenían que
apoyar a los equipos que acumulaban deudas. Los costes adicionales se producían
durante las canalizaciones de entrega y en producción.

La eliminación del período de estabilización mejoró rápidamente la forma en que los

equipos administraban su deuda. En lugar de abandonar el trabajo de mantenimiento
clave en el período de estabilización, los equipos que acumulaban deuda tenían que
dedicar el siguiente sprint a recuperar sus objetivos de deuda. Los equipos aprendieron
rápidamente a administrar su deuda de pruebas durante los sprints. Las características
se entregan cuando se han probado y justifican el coste de la implementación.
Automatización completa de canalizaciones
Gran parte de las mejoras que pueden obtener los equipos inmediatamente es la
automatización completa de las canalizaciones del repositorio de código a producción.
La automatización incluye la liberación de canalizaciones con integración continua (CI),
pruebas automatizadas y entrega continua (CD).

Los equipos podrían evitar la implementación porque es difícil, pero cuanto menor es la
implementación, más difícil es. Cuanto más tiempo pasa entre implementaciones, más
problemas se acumulan. Si el código no está actualizado, hay deuda de implementación.

Es más fácil trabajar en fragmentos más pequeños mediante la implementación

frecuente. Esta idea podría parecer obvia a posteriori, pero en el momento puede
parecer contraria a la lógica. Las implementaciones frecuentes también motivan a los
equipos a priorizar la creación de herramientas y canalizaciones de implementación más
eficaces y fiables.

Uso de herramientas internas

Microsoft usa el sistema de administración de versiones que compilan y lo envía a los
clientes. Una sola inversión mejora la productividad del equipo y los productos de
Microsoft. El uso de un sistema secundario reduciría el desarrollo y la velocidad de
entrega.

Autonomía y responsabilidad del equipo

Ningún indicador clave de progreso (KPI) específico mide la productividad o el
rendimiento del equipo, o si una característica va por buen camino. Los equipos deben
poder administrar sus propios planes y trabajos pendientes, al tiempo que encuentran
una manera de alinearse con los objetivos de la organización.

Es importante comunicarse directamente con los equipos para realizar un seguimiento

del progreso. Las herramientas deben facilitar la comunicación, pero la conversación es
la forma más transparente de comunicarse.

Priorizar características
Un objetivo importante es centrarse en la entrega de características. Las programaciones
pueden evaluar cuánto pueden completar los equipos y las personas razonablemente
durante un período de tiempo determinado, pero algunas características se entregarán
antes y otras más tarde. Los equipos pueden priorizar el trabajo para que las
características más importantes lleguen a producción.

Uso de microservicios
Los microservicios ofrecen diversas ventajas técnicas que mejoran y simplifican la
entrega. Los microservicios también proporcionan límites naturales para la propiedad
del equipo. Cuando un equipo tiene autonomía sobre la inversión en un microservicio,
puede priorizar cómo implementar características y administrar la deuda. Los equipos
pueden centrarse en los planes de factores como el control de versiones,
independientemente de los servicios generales que dependen del microservicio.

Trabajo en la rama principal

Los ingenieros solían trabajar en ramas independientes. La deuda combinada de cada
rama crecía hasta que el ingeniero intentaba integrar su rama en la rama principal.
Cuantos más equipos e ingenieros había, mayor era la integración.

Para que la integración se produzca más rápido, de forma más continua y en

fragmentos más pequeños, los ingenieros trabajan ahora en la rama principal. Una gran
razón para pasar a Git era la bifuración ligera que ofrece Git. La ventaja para la
ingeniería interna era eliminar la jerarquía de ramas profundas y sus residuos. Todo el
tiempo que solía dedicarse a la integración ahora se vierte en la entrega.

Uso de marcas de características

Algunas características no están completamente finalizadas para una implementación de
sprint, pero pueden beneficiarse igualmente de las pruebas en producción. Los equipos
pueden combinar e implementar este código con marcas de características para activar
la característica para usuarios específicos, como el equipo de desarrollo o un pequeño
segmento de usuarios pioneros. Las marcas de características controlan la exposición sin
arriesgarse a problemas con la base de usuarios general y pueden ayudar a los equipos
a determinar si hay que completar la característica y cómo hacerlo.

Pruebas en producción
El desplazamiento de pruebas a la derecha en producción ayuda a garantizar que las
pruebas de preproducción sean válidas y que los entornos de producción siempre
cambiantes estén listos para controlar las implementaciones.
Instrumentar pruebas y métricas
Independientemente de dónde se implemente una aplicación, es importante
instrumentar todo. La instrumentación no solo ayuda a identificar y corregir problemas,
sino que puede proporcionar una investigación valiosa sobre el uso y sobre qué agregar
a continuación.

Patrones de resistencia de pruebas

Un riesgo para las implementaciones complejas son los errores en cascada, en los que
un error de componente hace que se produzca un error en los componentes
dependientes, etc. hasta que se descompone todo el sistema. Es importante
comprender dónde están los puntos únicos de error (SPOF) y cómo se mitigan, y probar
los procesos de mitigación, especialmente en producción.

Elegir las métricas adecuadas

El diseño de métricas puede ser difícil. Un error común es incluir demasiadas métricas
para evitar que falte nada. Pero esto puede provocar omisiones o desconfianza en el
valor de las métricas que no satisfacen una necesidad específica. En su lugar, los
equipos de Microsoft dedican tiempo a determinar los datos que necesitan para medir
el éxito. Los equipos pueden agregar o cambiar métricas, pero comprender el propósito
desde el principio facilita ese proceso.

Además de la base de una métrica, los equipos consideran lo que necesitan que mida la
métrica. Por ejemplo, la velocidad o aceleración de las ganancias del usuario podría ser
una métrica más útil que el número total de usuarios. Las métricas varían de un
proyecto a otro, pero las más útiles son las que tienen el potencial de impulsar las
decisiones empresariales.

Uso de métricas para guiar el trabajo

Microsoft incluye métricas con revisiones en los niveles de liderazgo más altos. Cada
seis semanas, las organizaciones presentan su situación en cuanto a telemetría de salud,
empresa, escenarios y clientes. Las organizaciones discuten las métricas con los
ejecutivos y sus equipos.

Los equipos de toda la organización examinan las métricas de usuario en curso para
determinar el significado de sus características. Los equipos no solo envían
características, sino que miran si las personas las usan y cómo las usan. Los equipos
usan estas métricas para ajustar los trabajos pendientes y determinar si las
características necesitan más trabajo para cumplir los objetivos.

Directrices de entrega
Ir de A a B no es nunca una línea recta, y B no es el final.
Siempre habrá retrocesos y errores.
Vea los retrocesos como oportunidades de aprendizaje para cambiar las tácticas
para completar una parte determinada del proceso.
Con el tiempo, cada equipo desarrolla sus prácticas de DevOps a partir de la
experiencia y ajustando para responder a necesidades cambiantes.
La clave es centrarse en entregar valor, tanto a los usuarios finales como al propio
proceso de entrega.
Introducción al uso de sistemas fiables
con DevOps
Artículo • 05/10/2023

La fase de operaciones de DevOps viene después de una entrega bien realizada y

engloba todo lo que los equipos deben tener en cuenta para mantener, supervisar y
solucionar problemas de la aplicación. La compilación se expone a clientes reales en el
entorno de producción, donde la fiabilidad se convierte en un factor elemental.

Administrar exposición de versiones

La implementación del producto en el entorno de producción podría parecerse al paso
final, pero solo es el principio de todo un mundo nuevo. Hay muchas cosas que pueden
ir mal, por lo que es importante que los equipos pongan en práctica procedimientos de
implementación seguros que den el equilibrio adecuado entre exposición y riesgo de
los clientes. Los equipos también pueden probar añadiendo cambios con marcas de
funciones para saber cómo afectan las nuevas actualizaciones y funcionalidades a una
audiencia potencial.

Operar al máximo potencial

Los equipos deben asegurarse de que los sistemas con los que operan siempre están
disponibles, independientemente de las actualizaciones, los cambios o los problemas
subyacentes. Estar al tanto de todo requiere conocimientos sólidos de todas las
herramientas y funciones disponibles para supervisar los sistemas de producción. El
método correcto puede garantizar que los sistemas reciban actualizaciones y sigan
funcionando sin tiempo de inactividad.

Implementaciones de producción seguras

La seguridad se ha convertido en la preocupación central en las aplicaciones.
DevSecOps describe el conjunto de procedimientos que un equipo sigue para crear y
mantener sistemas que sean lo más seguros posible. Estas prácticas trascienden la
edición del código y la infraestructura para incluir también directrices para que las
personas las sigan, así como instrucciones para controlar y recuperarse de posibles
ataques.

Pasos siguientes
Descubra cómo una supervisión efectiva garantizar una alta disponibilidad del sistema y
permite a los equipos de DevOps ofrecer resultados rápidamente.
¿Qué es la supervisión?
Artículo • 05/10/2023

Una vez implementada una aplicación en producción, la fase de supervisión ofrece

información sobre el rendimiento y los patrones de uso de la aplicación para poder
identificar, mitigar o resolver problemas.

Objetivos de la supervisión
Unos de los objetivos de la supervisión es lograr una alta disponibilidad minimizando las
métricas clave que se miden en términos de tiempo:

Tiempo de detección (TTD): cuando surgen problemas de rendimiento u otras

incidencias, los datos de diagnóstico enriquecidos sobre los problemas se
trasladan a los equipos de desarrollo a través de la supervisión automatizada.
Tiempo de mitigación (TTM): los equipos de DevOps actúan sobre la información
para mitigar los problemas lo antes posible para que los usuarios ya no se vean
afectados.
Tiempo de corrección (TTR): se calculan los tiempos de resolución y los equipos
trabajan para mejorar con los plazos. Después de la mitigación, los equipos
trabajan en cómo subsanar la causa principal de los problemas para que no se
repitan.

Un segundo objetivo de la supervisión es habilitar el aprendizaje validado mediante el

seguimiento del uso. El concepto básico del aprendizaje validado es que cada
implementación es una oportunidad para realizar un seguimiento de los resultados
experimentales que admiten o reducen las hipótesis que llevaron a la implementación.
El seguimiento del uso y las diferencias entre versiones permite a los equipos medir el
impacto del cambio y fomentar la toma de decisiones de la organización. Si se reduce
una hipótesis, el equipo puede fracasar y responder rápido a los errores o dinamizarlos.
Si se acepta la hipótesis, el equipo puede doblar los esfuerzos o perseverar. Estas
decisiones fundamentadas por datos conducen a nuevas hipótesis y a la priorización del
trabajo pendiente.

Conceptos clave
La telemetría es el mecanismo para recopilar datos de la supervisión. La telemetría
puede usar agentes instalados en entornos de implementación, un SDK que se base en
marcadores insertados en el código fuente, registro de servidores o una combinación de
estos. Normalmente, la telemetría distinguirá entre el procesamiento de datos
optimizado para alertas en tiempo real y paneles y datos de mayor volumen necesarios
para solucionar problemas o análisis de uso.

La supervisión sintética usa un conjunto de transacciones para evaluar el rendimiento y

la disponibilidad. Las transacciones sintéticas son pruebas predecibles que tienen la
ventaja de permitir la comparación de versión a versión de forma muy previsible. La
supervisión de usuarios reales (RUM), por otro lado, analiza la experiencia del explorador
del usuario, el dispositivo móvil o el equipo de escritorio. Esto tiene en cuenta
condiciones de último tramo, como redes de telefonía móvil, enrutamiento de Internet y
almacenamiento en caché. A diferencia de las sintéticas, RUM normalmente no aporta
indicadores repetibles a lo largo del tiempo.

La supervisión se suele usar para pruebas en fase de producción. Una implementación

bien supervisada transmite datos sobre su estado y rendimiento para que se puedan
detectar incidencias de producción de inmediato. En combinación con un proceso de
creación de versión de implementación continua, la supervisión detectará nuevas
anomalías y favorecerá su rápida mitigación. Esto permite detectar los eventos
desconocidos en la actividad de la aplicación que no se pueden prever en entornos de
preproducción.

La supervisión eficaz es esencial para permitir que los equipos de DevOps entreguen
antes, reciban comentarios del equipo de producción y aumenten la satisfacción, la
adquisición y la retención de clientes.

Pasos siguientes
Obtenga más información sobre las funcionalidades de supervisión de Azure Monitor .
Descubra cómo configurar y usar Application Insights para la supervisión .
Procedimientos de implementación
seguros
Artículo • 05/10/2023

A veces, una versión no cumple las expectativas. A pesar de usar los procedimientos
recomendados y pasar todos los niveles de calidad, en ocasiones surgen incidencias que
producen una implementación de producción que causa problemas imprevistos a los
usuarios. Para minimizar y mitigar el impacto de estos problemas, se recomienda a los
equipos de DevOps adoptar una estrategia de exposición progresiva que equilibre la
exposición de una versión determinada con su rendimiento demostrado. A medida que
se demuestra la efectividad de una versión en la fase de producción, estará disponible
para niveles de audiencias más amplias hasta que todos los usuarios la usen. Los
equipos pueden usar procedimientos de implementación seguros para maximizar la
calidad y la velocidad de las versiones en producción.

Controlar la exposición a los clientes

Los equipos de DevOps pueden hacer uso de diversos procedimientos para controlar la
exposición de actualizaciones a los clientes. Históricamente, las pruebas A/B han sido
una opción popular entre los equipos que buscan ver cómo funcionan las distintas
versiones de un servicio o una interfaz de usuario con respecto a los objetivos fijados.
Las pruebas A/B también son relativamente fáciles de usar, ya que los cambios suelen
ser menores y, a menudo, solo comparan versiones diferentes en el aspecto de un
servicio orientado al cliente.

Implementación segura a través de anillos

A medida que las plataformas crecen, la escala de la infraestructura y las necesidades de
la audiencia también tienden a crecer. Esto crea una demanda de un modelo de
implementación que compensa los riesgos asociados a una nueva implementación con
las ventajas de las actualizaciones que promete. La idea general es que una versión
determinada debe exponerse primero solo a un pequeño grupo de usuarios con la
mayor tolerancia al riesgo. Luego, si la versión funciona según lo previsto, se puede
exponer a un grupo más amplio de usuarios. Si no hay ningún problema, el proceso
puede continuar en grupos más amplios de usuarios o anillos, hasta que todos usen la
nueva versión. Con las plataformas de entrega continua modernas, como GitHub
Actions y Azure Pipelines , la creación de un proceso de implementación con anillos
es algo accesible para los equipos de DevOps de cualquier tamaño.
Marcas de característica
A veces, es necesario implementar cierta funcionalidad como parte de una versión, pero
no se expone de forma inicial a los usuarios. En estos casos, marcas de funciones
ofrecen una solución en la que la funcionalidad se puede habilitar a través de cambios
de configuración en función del entorno, el anillo o cualquier otra implementación
específica.

Participación del usuario

De forma similar a las marcas de funciones, la participación del usuario es una manera
de limitar la exposición. En este modelo, una función determinada se habilita en la
versión, pero no se activa para un usuario a menos que lo desee específicamente. La
decisión de tolerancia al riesgo pasa a los usuarios para que puedan decidir la rapidez
con la que desean aceptar determinadas actualizaciones.

Normalmente, se emplean varios procedimientos a la vez. Por ejemplo, un equipo

puede tener una función experimental destinada a un caso práctico muy específico.
Como es arriesgado, la implementarán en el primer anillo para que los usuarios internos
la prueben. Sin embargo, aunque las funciones están en el código, alguien debe incluir
la marca de funciones en una implementación específica dentro del anillo para que la
función se exponga a través de la interfaz de usuario. Incluso en ese caso, la marca de
función solo puede exponer la opción para que un usuario se decida a usar la nueva
función. Cualquier persona que no esté en el anillo, en esa implementación o no sea
participante no se expondrá a la función. Aunque se trata de un ejemplo bastante
rebuscado, sirve para ilustrar la flexibilidad y la viabilidad de la exposición progresiva.

Problemas comunes con los que los equipos se

encuentran al principio
A medida que los equipos avanzan en un procedimiento más ágil de DevOps, pueden
detectar los mismos problemas que otros que han migrado de entregas monolíticas
tradicionales. Los equipos solían implementar una vez cada pocos meses porque tienen
una mentalidad que apuesta por la estabilización. Esperan que cada implementación
introduzca un cambio sustancial en el servicio y que haya problemas imprevistos.

Las cargas son demasiado grandes

Los servicios que se implementan cada pocos meses suelen llenarse de muchos
cambios. Esto aumenta la probabilidad de que salgan problemas de inmediato y
también dificulta la solución de estos por la cantidad de elementos nuevos. Al pasar a
entregas más frecuentes, las diferencias en lo que se implementa se vuelven más
pequeñas, lo que permite realizar pruebas más dirigidas y facilitar la depuración.

Sin aislamiento de servicios

Los sistemas monolíticos escalan tradicionalmente mediante la mejora del hardware en
el que se implementan. Sin embargo, cuando algo va mal con la instancia, esto da lugar
a que a todos tengan problemas. Una solución sencilla consiste en añadir varias
instancias para que pueda equilibrar la carga de los usuarios. Sin embargo, esto puede
necesitar elementos de arquitectura importantes, ya que muchos sistemas heredados no
están creados para ser de varias instancias. Además, es posible que se haga necesario
asignar recursos duplicados significativos para la funcionalidad que se pueda consolidar
mejor en otro lugar.

A medida que se añaden nuevas funciones, investigue si haya alguna arquitectura de

microservicios que pueda ayudarle a operar y escalar gracias a un mejor aislamiento del
servicio.

Los procesos manuales llevan a error

Cuando un equipo solo implementa varias veces al año, la automatización de las
entregas puede parecer algo que no merezca la pena. Como consecuencia, muchos
procesos de implementación se administran de forma manual. Esto requiere una
cantidad significativa de tiempo y esfuerzo y tiende a que se produzcan errores
humanos. Solo hay que automatizar las tareas de compilación e implementación más
comunes para reducir el tiempo malgastado y los errores no forzados.

Los equipos también pueden usar la infraestructura como código para tener un mejor
control sobre los entornos de implementación. Esto elimina la necesidad de enviar
solicitudes al equipo de operaciones para realizar cambios manuales a medida que se
introducen nuevas funciones o dependencias en varios entornos de implementación.

Solo el equipo de operaciones puede realizar

implementaciones
Algunas organizaciones tienen directrices y políticas que exigen que el personal de
operaciones inicie y administre todas las implementaciones. Aunque puede haber
habido buenas razones para eso en el pasado, un proceso ágil de DevOps se beneficia
enormemente cuando el equipo de desarrollo puede iniciar y controlar las
implementaciones. Las plataformas de entrega modernas ofrecen un control
pormenorizado sobre quién puede iniciar las implementaciones y quién puede acceder
a los registros de estado y a otra información de diagnóstico, asegurando de que las
personas adecuadas tengan la información adecuada lo antes posible.

Las implementaciones incorrectas prosiguen y no pueden

revertirse
A veces, una implementación no funciona correctamente y los equipos necesitan
resolverla. Sin embargo, cuando los procesos son manuales y el acceso a la información
es lento y limitado, puede ser difícil revertir a una implementación en curso anterior.
Afortunadamente, hay varias herramientas y procedimientos que reducen el riesgo de
las implementaciones con errores.

Principios básicos
Los equipos que buscan adoptar procedimientos de implementación seguros deben
establecer algunos principios básicos para reforzar la labor.

Uniformidad
Las mismas herramientas que se usan para implementar en producción deben usarse en
entornos de desarrollo y pruebas. Si hay problemas, como los que a menudo surgen de
nuevas versiones de dependencias o herramientas, deben detectarse debidamente
antes de que el código esté a punto de publicarse en producción.

Atención a los indicadores de calidad

Demasiados equipos caen en la trampa habitual de no preocuparse realmente por los
indicadores de calidad. Con el tiempo, se pueden dar cuenta de que escriben pruebas o
toman tareas de calidad solo para cambiar de una advertencia amarilla a una
aprobación verde. Los indicadores de calidad son realmente importantes, ya que son el
pulso de un proyecto. Se debe realizar un seguimiento constante diario de las señales
de calidad que se usan para aprobar las implementaciones.

Las implementaciones deben incluir un tiempo de

inactividad cero
Aunque no es vital que todos los servicios estén siempre disponibles, los equipos deben
afrontar las fases de entrega y operaciones de DevOps con la idea de que pueden y
deben implementar versiones nuevas sin que sea necesario quitarlas. Las herramientas
modernas de infraestructura y procesos son lo suficientemente avanzadas, porque ya es
posible que prácticamente cualquier equipo tenga como objetivo un tiempo de
actividad del 100 %.

Las implementaciones deben realizarse durante el horario

laboral
Si un equipo trabaja con la mentalidad de que las implementaciones requieren un
tiempo de inactividad cero, no importará en qué momento se inserta una
implementación. Además, resulta ventajoso insertar implementaciones durante las horas
de trabajo, especialmente a horas tempranas del día y a principios de semana. Si algo va
mal, se debe rastrear lo antes posible como para controlar el radio de explosión.
Además, todos los usuarios estarán trabajando y centrados en subsanar los problemas.

Implementación basada en anillos

Los equipos que usan procedimientos de versiones bien desarrollados de DevOps están
en la posición para asumir la implementación basada en anillos. En este modelo, las
nuevas funciones se implementan primero para los clientes dispuestos a aceptar el
máximo riesgo. A medida que se va mostrando la implementación, la audiencia se
amplía para incluir a más usuarios hasta que todos la usen.

Un modelo de anillos de ejemplo

Un modelo de implementación de anillo típico está diseñado para detectar problemas
lo antes posible a través de la segmentación cuidadosa de los usuarios y la
infraestructura. En el ejemplo siguiente se muestra cómo usa los anillos un equipo
principal de Microsoft.

En Propósito Usuarios Centro de datos

anillo

0 Busca la mayoría de errores De uso solo interno con alta Centro-oeste de EE.
que afectan al usuario tolerancia a riesgos y errores UU.
introducidos por la
implementación

1 Áreas que el equipo no prueba Clientes que usan gran parte Un pequeño centro de
exhaustivamente del producto datos

2 Problemas relacionados con la Cuentas públicas, Un centro de datos

escala preferentemente gratuitas mediano o grande
 En Propósito con un grupo diverso de
Usuarios Centro de datos
anillo funciones

3 Problemas de escalado en Cuentas internas grandes y Centro de datos

cuentas internas y problemas clientes europeos interno y centro de
de ámbito internacional datos europeo

4 Unidades de escalado Todos los demás Todos los destinos de

restantes implementación

Permitir tiempo de simulación mediante “bake”

El término tiempo de simulación mediante “bake” hace referencia a la cantidad de
tiempo que se permite que se ejecute una implementación antes de ampliarse y pasar al
siguiente anillo. Algunos problemas pueden tardar horas o más en empezar a reflejar
indicios por lo que la versión debe estar en uso durante un espacio de tiempo adecuado
antes de que se considere lista.

En general, un día de 24 horas debe ser suficiente tiempo para la mayoría de casos para
exponer errores latentes. Sin embargo, este período debe incluir un plazo de uso
máximo, que abarca un día laborable completo, para los servicios más demandantes
durante las horas laborables.

Acelerar revisiones
Una incidencia de sitio activo (LSI) se produce cuando un error tiene un impacto grave
en la producción. Las LSI requieren la creación de una revisión, que es una actualización
fuera de banda diseñada para solucionar un problema de alta prioridad.

Si un error es Sev 0, el tipo de error más grave, la revisión se puede implementar

directamente en la unidad de escalado afectada lo antes posible. Aunque es
fundamental que la corrección no empeore las cosas, los errores de esta gravedad se
consideran tan perjudiciales que deben solucionarse inmediatamente.

Los errores clasificados como Sev 1 deben implementarse a través del anillo 0, pero
luego se pueden implementar en las unidades de escalado afectadas tan pronto como
se apruebe.

Las revisiones de errores con una gravedad inferior deben implementarse a través de
todos los anillos según lo previsto.

Puntos clave
El propósito de cada equipo es entregar las actualizaciones rápidamente y con la mayor
calidad posible. Con los procedimientos adecuados, la entrega puede ser una parte
productiva y carente de obstáculos del ciclo de DevOps.

Implemente con frecuencia.

Mantenga un buen ritmo a lo largo del sprint.
Use herramientas de implementación acordes en la fases de desarrollo, pruebas y
producción.
Use una plataforma de entrega continua que permita la automatización y la
autorización.
Siga procedimientos de implementación seguros.

Pasos siguientes
Descubra cómo las marcas de funciones ayudan a controlar la exposición de nuevas
funciones a los usuarios.
Experimentación progresiva con marcas
de funciones
Artículo • 05/10/2023

A medida que los equipos de DevOps cambian a una metodología ágil que se centra en
la entrega continua de funciones, la necesidad de controlar de qué forma quedan
disponibles para los usuarios se vuelve cada vez más importante. Las marcas de
funciones son una excelente solución para limitar el acceso de los usuarios a nuevas
funciones, ya sea con fines de marketing o para pruebas en producción.

Desacoplamiento de la implementación y
exposición
Con las marcas de funciones, un equipo puede determinar si un conjunto determinado
de funciones sea visible en la experiencia del usuario o se invoca dentro de la
funcionalidad. Las nuevas funciones se pueden compilar e implementar como parte del
proceso de desarrollo normal sin que a esas funciones se les dé un acceso generalizado.
La implementación de funciones se desacopla debidamente de su exposición.

Las marcas dan control a un usuario en concreto en el

tiempo de ejecución
Las marcas también dan a un usuario en concreto un control granular y completo.
Cuando es el momento de habilitar una función, ya sea para un usuario, un grupo
pequeño o todo el mundo, el equipo cambia la marca de función para activarla sin tener
que volver a implementarla.

El tipo de uso de una marca de función variará según la naturaleza de la función y del
público. En algunos casos, una marca de función habilitará automáticamente la
funcionalidad para todos los usuarios. En otros casos, se habilitará una función por
usuario. Los equipos también pueden usar marcas de funciones para que los usuarios
puedan habilitar una función, si así lo desean. Realmente no hay ningún límite en la
forma en que se implementan las marcas de funciones.

Incluir comentarios y experimentación en una fase

temprana
Las marcas de funciones son una excelente manera de incorporar el proceso de
experimentación en fase temprana. Algunas funciones pueden presentar ciertas aristas
al principio, lo que puede ser interesante solo para usuarios en la primera fase. Si se
intenta habilitar estas funciones sin preparar a un público más amplio, esto podría
generar insatisfacción. La ventaja de reunir comentarios de usuarios dispuestos a
trabajar con una función en desarrollo es incalculable.

Desactivación rápida
A veces resulta útil poder desactivar algo. Por ejemplo, supongamos que hay una nueva
función que no responde según lo previsto y hay efectos secundarios que causan
problemas en otro lugar. Puede usar marcas de funciones para desactivar rápidamente
la nueva funcionalidad y así revertir la acción de confianza sin tener que volver a
implementar. Aunque las marcas de funciones suelen tener considerar funciones de
interfaz de usuario, también se pueden usar fácilmente para cambios en la arquitectura
o la infraestructura.

Fases estándar
Microsoft hace uso de un proceso de implementación estándar para activar las marcas
de funciones. Hay dos conceptos independientes: anillos, que son para las
implementaciones y fases, que son para las marcas de funciones. Obtenga más
información sobre los anillos y las fases .

Las fases tienen que ver con la difusión o la exposición. Por ejemplo, la primera fase
podría ser para la cuenta de un equipo y las cuentas personales de los miembros. La
mayoría de usuarios no verían nada nuevo porque las únicas marcas de posición
activadas son de esta primera fase. Esto permite que un equipo las aproveche en su
totalidad y experimente con ellas. Una vez que el equipo cierra la sesión, los clientes
seleccionados podrán participar a través de la segunda fase de las marcas de funciones.

Participar
Se recomienda permitir a los usuarios participar en las marcas de funciones si es factible.
Por ejemplo, el equipo puede exponer un panel de vista previa asociado a las
preferencias o la configuración del usuario.
Usar marcas con telemetría
Las marcas de funciones brindan una forma de exponer actualizaciones de forma
gradual. Sin embargo, los equipos deben supervisar continuamente las métricas
adecuadas para evaluar la fase de preparación para una exposición más amplia. Estas
métricas deben incluir la actividad de uso, así como el impacto de las actualizaciones en
el estado del sistema. Es importante evitar la trampa de asumir que todo está bien solo
porque no parece que esté pasando nada malo.

Ejemplo de marca de función

Veamos el siguiente ejemplo. El equipo ha añadido aquí un par de botones para Cherry-
pick (Selección exclusiva) y Revert (Volver) en la interfaz de usuario de solicitud de
incorporación de cambios. Esto se implementaron mediante marcas de funciones.
Definir marcas de funciones
La primera función expuesta era el botón Revert (Volver). La solución usa un archivo
XML para definir todas las marcas de funciones. En este caso, hay un archivo por
servicio, que crea un incentivo para quitar marcas antiguas y evitar que la sección sea
demasiado larga. El equipo eliminará las marcas antiguas por la motivación natural por
controlar el tamaño de ese archivo.

XML

<?xml version="1.0" encoding="utf-8"?>

<!--
In this group we should register Azure DevOps specific features and sets
their states.
-->
<ServicingStepGroup name="AzureDevOpsFeatureAvailability" … >
<Steps>
<!-- Feature Availability -->
<ServicingStep name="Register features"
stepPerformer="FeatureAvailability" … >
<StepData>
<!--specifying owner to allow implicit removal of features -->
<Features owner="AzureDevOps">
<!-- Begin TFVC/Git -->
<Feature name="[Link]" description="Source control
revert features" />

Una estructura de servidor común fomenta la reutilización y las economías de escala en

todo el equipo. En teoría, el proyecto tendrá la infraestructura necesaria para que un
desarrollador pueda definir una marca en un almacén central y tener el resto de la
infraestructura controlada para ellos.

Comprobar marcas de funciones en tiempo de ejecución

La marca de función que se usa aquí se denomina [Link]. Este es el
TypeScript real de la página que refleja la llamada a una comprobación de
disponibilidad de funciones.

TypeScript

private addRevertButton(): void {

if ([Link]([Link])) {
this._calloutButtons.unshift(
<button onClick={ () => [Link](
[Link],
[Link](),
 [Link]().sourceBranchStatus,

[Link]().targetBranchStatus)
}
>
{VCResources.PullRequest_Revert_Button}
</button>
);
}
}

En el ejemplo anterior se representa el uso en TypeScript, pero se puede acceder igual

de fácil mediante C#. El código comprueba si la función está habilitada y, si es así,
representa un botón para mostrar la funcionalidad. Si la marca no está habilitada, se
omitirá el botón.

Controlar una marca de función

Una buena plataforma de marcas de funciones facilitará varias maneras de administrar si
se establece una marca determinada. Normalmente, hay casos en los que la marca se
controla a través de PowerShell y la interfaz web. En PowerShell, todo lo que debe
exponerse son formas de obtener y establecer el estado de una marca de función, junto
con parámetros opcionales para elementos, como identificadores de cuenta de usuario
específicos, si procede.

Controlar marcas de funciones a través de la interfaz de

usuario web
En el ejemplo siguiente se usa la interfaz de usuario web de este producto expuesta por
el equipo. Tenga en cuenta la marca de función de [Link]. Hay dos
cuentas personales que aparecen aquí: hallux y buckh-westeur. El estado cambia a
hallux, que se ejecuta en Centro-norte y se borra en la otra cuenta en Oeste de Europa.
La naturaleza de la marca de función determinará la forma en que se exponen las
funciones. En algunos casos, la exposición seguirá un modelo de anillo y fase. En otros,
los usuarios pueden optar por la interfaz de usuario de configuración o incluso enviando
un correo electrónico al equipo para obtener acceso.

Observaciones sobre las marcas de funciones

La mayoría de las marcas de funciones se pueden retirar una vez que se ha
implementado una función para todos los usuarios. En ese momento, el equipo puede
eliminar todas las referencias a la marca en el código y la configuración. Se recomienda
incluir una revisión de marcas de funciones, como al principio de cada sprint.

Al mismo tiempo, puede haber un conjunto de marcas de funciones que se conserven

por diversos motivos. Por ejemplo, es posible que el equipo quiera mantener una marca
de función que se ramifique para algo infraestructural durante un período de tiempo
después de que el servicio de producción haya cambiado completamente. Sin embargo,
tenga en cuenta que esta posible ruta de código podría reactivarse en el futuro durante
una desactivación expresa de la marca de función, por lo que debe probarse y
mantenerse hasta que se quite la opción.
Marcas de funciones y estrategia de bifurcación
Las marcas de funciones permiten a los equipos de desarrollo incluir funciones
incompletas en main sin afectar a nadie más. Siempre que la ruta de código esté aislada
detrás de una marca de función, generalmente no hay problema en compilar y publicar
ese código sin que se produzcan efectos secundarios que afecten al uso normal. Pero si
hay casos en los que una función requiere dependencias, como al exponer un punto de
conexión REST, los equipos deben tener en cuenta cómo esas dependencias pueden
crear tareas de seguridad o mantenimiento aunque no se exponga la función.

Marcas de funciones para mitigar el riesgo

A veces, las nuevas funciones son el origen de que se introduzcan cambios destructivos
o perjudiciales. Por ejemplo, en el producto se puede estar realizando una
transformación que pasa de un esquema de base de datos amplio a otro largo. En este
caso, el desarrollador debe crear una rama de funciones en un pequeño espacio de
tiempo. A continuación, este debe realizar cambios desestabilizadores en la rama y dejar
la función detrás de una marca. Lo que muchas veces se hace es que los equipos
combinen los cambios en main siempre que no causen ningún daño. Esto no sería
viable sin la opción de mantener oculta la función sin terminar detrás de una marca de
función.

Las marcas de funciones ayudan a trabajar en main

Si sigue los procedimientos lógicos en la fase de desarrollo, trabajar en main es una
buena manera de ajustar un ciclo de DevOps. Cuando esto se acompaña de marcas de
funciones, los desarrolladores pueden combinar rápidamente funciones ascendentes e
insertarlas a través de la batería de pruebas. El código de calidad puede publicarse
rápidamente para realizar pruebas en producción. Después de unos pocos sprints, los
desarrolladores reconocerán las ventajas de las marcas de funciones y las usarán de
forma proactiva.

Cómo decidir si se debe usar una marca de función

Los equipos de funciones tienen el poder de decisión si necesitan una marca de función
o no para un cambio determinado. No todos los cambios requieren una, por lo que será
criterio del desarrollador cuando necesiten realizar un cambio determinado. En el caso
de la función Revert (Volver) mencionada anteriormente, era importante usar una marca
de función para controlar la exposición. Permitir a los equipos tomar decisiones
importantes sobre el ámbito de funciones en el que trabajan forma parte de fomentar la
autonomía en una organización de DevOps eficaz.

Diferencias entre compilación y compra

Aunque es posible crear su propia infraestructura de marcas de funciones, generalmente
se recomienda usar una plataforma como LaunchDarkly . Es preferible invertir tiempo
en crear funciones en lugar de volver a generar la funcionalidad de la marca de función.

Pasos siguientes
Obtenga más información sobre cómo usar marcas de funciones en una aplicación
[Link] Core.
Eliminar tiempo de inactividad nulo
mediante actualizaciones de servicio
con versiones
Artículo • 05/10/2023

Tradicionalmente, los administradores necesitaban desconectar un servidor para

actualizar y mejorar el software local. Sin embargo, el tiempo de inactividad se hace
totalmente imposible para servicios globales ininterrumpidos. Muchos servicios en la
nube modernos son una dependencia crítica para que los usuarios operen con sus
empresas. Nunca es buen momento de quitar un sistema, así que ¿cómo puede un
equipo prestar servicio continuo al instalar actualizaciones importantes de seguridad y
funciones?

Mediante el uso de actualizaciones con versiones, estos servicios esenciales pueden

transicionar sin problemas de una versión a otra mientras los clientes los usan
activamente. No todas las actualizaciones son complejas. Las actualizaciones de diseños
o estilos de front-end son fáciles. Los cambios en las funciones pueden ser complicados,
pero hay procedimientos bien conocidos para mitigar los riesgos de migración. Sin
embargo, los cambios que derivan del nivel de datos plantean una nueva clase de
dificultades que merecen una consideración especial.

Actualizar capas por separado

Con un servicio en línea distribuido en varios centros de datos y un almacenamiento de
datos independiente, no todo puede cambiar simultáneamente. Si el servicio normal se
divide en código de aplicación y bases de datos, que probablemente tienen versiones
independientes entre sí, uno de esos entornos debe absorber la complejidad del control
de versiones.

A menudo, el control de versiones es más fácil de controlar en el código de la

aplicación. Los sistemas más grandes suelen tener bastante código heredado, como SQL
que reside dentro de sus bases de datos. En lugar de complicar aún más este CÓDIGO
SQL, el código de la aplicación debe controlar la complejidad. En concreto, puede crear
un conjunto de clases de fábrica que comprendan el control de versiones de SQL.

Durante cada sprint, cree una nueva interfaz con esa versión para que siempre haya
código que coincida con cada versión de base de datos. Puede dar marcha atrás
fácilmente los archivos binarios durante la implementación. Si algo va mal después de
implementar los nuevos archivos binarios, vuelva al código anterior. Si la
implementación binaria se realiza correctamente, inicie el mantenimiento de la base de
datos.

¿Cómo funciona esto realmente? Por ejemplo, supongamos que el equipo implementa
actualmente el Sprint 123. Los archivos binarios comprenden el esquema de la base de
datos de Sprint 123 y el esquema de Sprint 122. El patrón general es trabajar con ambas
versiones o sprints N y N-1 del esquema SQL. Los archivos binarios hacen una consulta
en la base de datos, determinan a qué versión de esquema se están dirigiendo y luego
cargan el enlace adecuado. A continuación, el código de la aplicación controla la
incidencia cuando el nuevo esquema de datos aún no está disponible. Una vez
disponible la nueva versión, el código de aplicación puede empezar a usar la nueva
funcionalidad habilitada por la versión de base de datos más reciente.

Puesta al día solo con el nivel de datos

Una vez actualizadas las bases de datos, el servicio entrará en estado de puesta al día si
se produce un problema. Las migraciones de bases de datos en línea son complejas y, a
menudo, necesitan varias fases, por lo que la fase de puesta al día suele ser la mejor
manera de solucionar un problema. En otras palabras, si se produce un error en la
actualización, es probable que también se produzca un error en la reversión. No tiene
mucho sentido invertir en la tarea de crear y probar código de reversión que el equipo
no tenga previsto usar nunca.

Secuencia de implementación
Piense en una situación en la que necesita añadir un conjunto de columnas a una base
de datos y transformar algunos datos. Esta transición no debe ser visible para los
usuarios, lo que significa evitar bloqueos de tabla tanto como sea posible y, a
continuación, mantener los bloqueos durante el menor tiempo posible para que no
sean perceptibles.

Lo primero que hacemos es manipular los datos, posiblemente en tablas paralelas

mediante un desencadenador SQL para tener los datos sincronizados. A veces, las
migraciones y transformaciones de datos de gran tamaño tienen que superar varias
implementaciones en varios sprints.

Una vez creados los datos adicionales o el nuevo esquema en paralelo, el equipo activa
el modo de implementación para el código de la aplicación. En el modo de
implementación, cuando el código realiza una llamada a la base de datos, primero toma
un bloqueo en el esquema y, a continuación, lo libera después de ejecutar el
procedimiento almacenado. La base de datos no puede cambiar entre el momento en
que se realice la llamada a la base de datos y cuando se ejecuta el procedimiento
almacenado.

El código de actualización actúa como escritor de esquemas y solicita un bloqueo de

escritura en el esquema. El código de aplicación tiene prioridad al tomar un bloqueo del
lector y el código de actualización se activa en segundo plano intentando obtener el
bloqueo del escritor. En el bloqueo del sistema de escritura, solo se permite un pequeño
número de operaciones muy rápidas en las tablas. A continuación, se libera el bloqueo y
la aplicación registra la nueva versión de la base de datos en uso y usa la interfaz que es
la misma que la nueva versión de la base de datos.

Todas las actualizaciones de la base de datos se realizan mediante un patrón de

migración. Un conjunto de código y scripts examina la versión de la base de datos y, a
continuación, realiza cambios graduales para migrar el esquema de la versión anterior a
la nueva. Todas las migraciones se automatizan e implementan a través del servicio de
administración de versiones.

La interfaz de usuario web también debe actualizarse sin afectar a los usuarios. Al
actualizar archivos de JavaScript, hojas de estilos o imágenes, evite mezclar versiones
antiguas y nuevas cargadas por el cliente. Esto puede llevar a errores que podrían hacer
perder el trabajo en curso, como un campo que edita un usuario. Por lo tanto, debe
crear versiones de todos los archivos JavaScript, CSS y de imagen colocando todos los
archivos asociados a una implementación en una carpeta independiente con versiones.
Cuando la interfaz de usuario web realiza llamadas de nuevo al nivel de la aplicación, se
cargan los recursos con una versión especificada. Solo cuando la acción de un usuario
da como resultado una actualización de página completa, la nueva interfaz de usuario
web se carga en el explorador. La actualización no afecta a la experiencia del usuario.

Pasos siguientes
Microsoft ha sido una de las empresas de desarrollo de software más grandes del
mundo durante décadas. Descubra cómo Microsoft opera en sistemas fiables con
DevOps.
Cómo opera Microsoft en sistemas
fiables con DevOps
Artículo • 05/10/2023

Microsoft ha estado operando en plataformas en línea complejas desde los primeros

días del Internet comercial. Durante todo este tiempo, hemos ido evolucionado una
serie de prácticas esenciales para que los sistemas estén siempre disponibles, gocen de
un buen estado y sean seguros. Estas prácticas forman parte de una iniciativa más
grande para mantener y mejorar una cultura de sitio activo.

Cultura de sitio activo

La cultura de sitio activo es la pieza central de una organización para priorizar la
experiencia y la fiabilidad del sitio activo sobre todo lo demás. Después de todo, los
clientes pueden tratar con proveedores de servicios de forma bastante sencilla hoy en
día con los servicios basados en internet y en la nube, dando una considerablemente
importancia a la confianza del cliente. El sitio activo siempre debe estar disponible y
cumplir lo que promete a los clientes.

Existen varios factores que contribuyen a una cultura de sitio activa adecuada.

El sitio activo primero

Colocar primero la experiencia del sitio activo es integral para una plataforma de éxito.
Los equipos no pueden poner toda su atención en las nuevas y más destacadas
funciones e ignorar el entorno en el que se presenten dichas funciones a los usuarios.
Basamos nuestro hacer en prácticas de implementación seguras que permiten
garantizar que nuestros clientes disfruten de un acceso ininterrumpido a la plataforma.
Esto puede resultar especialmente complicado cuando se trata de publicar
actualizaciones de servicio con versiones sin tiempo de inactividad.

Controlar la exposición a través de marcas de funciones

A medida que implementamos a través de nuestros anillos y fases, controlando la
exposición con marcas de funciones, ocasionalmente detectamos un problema en la
fase de producción. A pesar de toda la automatización y comentarios, hay cosas que a
veces siguen pasando. Como se suele decir, ¡la producción es lo que tiene!

Normalmente, los controles de estado y la telemetría nos avisa cuando hay algo que no
está bien. Un desarrollador puede crear una rama de main , aplicar una corrección y
solicitar la incorporación de cambios en main . Mantener el mismo flujo de trabajo
general significa que los desarrolladores no tengan que cambiar el contexto ni aprender
un proceso diferente para un cambio de código diferente.

Para hacer una implementación de revisiones, se necesita realizar un paso más, que
consiste en seleccionar el cambio en la rama de la versión. Ejecutamos una
implementación de revisión fuera de la rama de la versión actual cada día de la semana,
aunque también esto lo podemos según se pida si existen correcciones urgentes. La
corrección se aplica realmente primero en la producción fuera de la rama de la versión.
Pero como desarrollamos primero en main , sabemos que no se retrocederá del
siguiente sprint cuando se cree una nueva rama de versión a partir de main .

Las versiones de productos locales son en gran medida las mismas, aunque sin los
anillos y las fases de implementación. Además, dado que realizamos más pruebas
manuales en diferentes configuraciones y formas de datos, hay una cola más larga entre
cortar la rama de la versión y poner el producto en manos de los clientes.

La seguridad es algo que hay que tomarse personalmente

El objetivo es hacer que las vulnerabilidades sean reales y personales. Esto garantiza que
la gente se preocupe de verdad. También hacemos un amplio uso de juegos de guerra
para detectar y evitar riesgos de seguridad en todo el sistema, ya sea en el código o no.
Cuando el equipo rojo puede dar cuenta de han entrado en el código al activar un
cuadro de diálogo al revés, esto motiva al propietario del código para solucionar el
problema y asegurarse de que no se vuelva a producir en ningún otro aspecto. Ese tipo
de competencia es mucho más real y personal que una advertencia de análisis estática
sobre un riesgo de XSS potencial. Creamos este tipo de cultura y dinámica a través de
juegos de guerra y otros ejercicios de seguridad. La gente tiene disposición a piratear el
código de los demás o de ser capaz de bloquear los ataques de los otros. Esto infunde
una cultura de código segura.

No podemos planear todos las formas de ataque, pero lo que podemos hacer es
suponer que va a haber una vulneración y prever lo rápido que podemos reaccionar
ante esta filtración. Muchos de las tareas de seguridad se han movido en torno a esta
idea para nuestros equipos.

Además y por último, errar es humano. A veces son descuidados y hacen cosas como
almacenar contraseñas en recursos compartidos de archivos. Podemos decirles que no
lo hagan así y formarles en seguridad, así como muchas otras cosas. La mayoría de las
personas aprenden, pero solo se necesita una persona para llevar al traste el sistema. Se
puede tener todo tipo de listas de procedimientos recomendados, pero a menos que lo
materialice de verdad, debe asumir que las personas van a cometer errores. Para esto se
necesita un cierto nivel de supervisión para garantizar que se siguen los procesos más
esenciales.

El equipo de ingeniería es más que un grupo de

colaboradores de operaciones
Desde el principio, hemos aprendido que hacer que el sitio activo es una parte
importante de las responsabilidades del equipo de ingeniería. Eso supuso un gran
descubrimiento para nosotros porque, en el pasado, una persona implementaba algo,
descansaba el fin de semana y al volver el lunes, había recibido 900 problemas de
clientes que los equipos de atención al cliente y de operaciones tenían que solucionar
todo el fin de semana. Es importante que el equipo de ingeniería se encargue de los
problemas del sitio activo. De lo contrario, no hay ningún incentivo para crear sistemas
que eviten esos problemas. Esto lo tiene muy presente, cuando le llaman a las 2 de la
mañana para arreglar algo que rompió.

A medida fuimos desarrollando esta responsabilidad, la frase “El sitio activo es lo más
importante que hacemos” se convirtió en la máxima de todo el equipo. Lo que tienen
ellos ahora es la experiencia del cliente y no es solo algo impuesto. Es algo por lo que la
gente cuenta con nosotros y nos enorgullecemos de ello. Debe ser un aspecto
diferenciador de nuestro producto.
La telemetría en la producción es el latido que marca el
servicio
Para sobrevivir en un mundo con un ritmo tan rápido donde prácticamente cualquier
cosa puede ir mal, necesitamos sistemas de alertas excelentes. Las alertas poco
funcionales, las alertas redundantes o los volúmenes de alertas abrumadores consiguen
que se ignoren todas las alertas. Es fácil crear muchas alertas de más, por lo que el
proceso se reduce en una simple pregunta: ¿Es viable responder a esa alerta? Esto
garantiza que nos ocupemos de los problemas reales del cliente y los solucionemos lo
más rápido posible.

Cuando el equipo de ingeniería respondía a alertas funcionales, observaban que

muchos problemas de los que surgen, especialmente en mitad de la noche, suelen tener
correcciones similares, al menos temporalmente. Esto daba lugar a que se centren más
en los sistemas que estaban mejor en conmutación por error y recuperación automática.
Ahora los problemas se producen, generan alertas y después se solucionan lo suficiente
para que el equipo de ingeniería espere hasta la mañana para corregirlos. Esto no habría
ocurrido si el equipo de ingeniería se hubiera ocupado de los pequeños elementos de
código que hicieron que otras personas se quedaran en vela. Ahora trabajan para
equilibrar estas mejoras, no para garantizar la velocidad de las funciones, sino por la
velocidad de mejora del proceso de ingeniería.

Resumen
La aplicación de una cultura de sitio activa ha afectado a la forma en que Microsoft
compila y entrega el software. Al convertir a los equipos de ingeniería en una pieza
clave de la seguridad y las operaciones, la calidad de nuestro código y la experiencia del
usuario final han mejorado significativamente. Participar de manera integral en las
operaciones ha hecho que la ingeniería sea una parte interesada vital, lo que da lugar a
sistemas diseñados para mejorar las operaciones.
Seguridad en DevOps (DevSecOps)
Artículo • 05/10/2023

La seguridad es una parte clave de DevOps. ¿Pero cómo sabe un equipo si un sistema es
seguro? ¿Es de verdad posible ofrecer un servicio completamente seguro?

Por desgracia, la respuesta es no. DevSecOps es un trabajo continuo y siempre en

marcha que requiere la atención de todos los usuarios en las operaciones de desarrollo
y TI. Aunque no se termina nada como tal, los procedimientos que los equipos emplean
para evitar y controlar las filtraciones y ataques pueden ayudar a producir sistemas que
sean lo más seguros y resistentes posible.

“Básicamente, si alguien quiere entrar, va a entrar... Hay que aceptar eso. Esto es lo
que les decimos a los clientes es: primero, que la batalla nunca cesa, aunque creyera
que no. Y segundo, casi seguramente ya haya sufrido algún ataque”. -- Michael
Hayden, exdirector de la NSA y la CIA

La conversación sobre seguridad

Se recomienda a los equipos que no tengan una estrategia formal de DevSecOps para
empezar la planificación lo antes posible. Al principio, es posible que haya cierta
resistencia de los miembros del equipo que no aprecian plenamente las amenazas
existentes. Es posible que otros no sientan que el equipo está preparado para afrontar el
problema y que cualquier inversión especial será una distracción desperdiciada con
respecto al envío de funciones. Pero es necesario comenzar la conversación para crear
consenso sobre la naturaleza de los riesgos, cómo el equipo puede mitigarlos y si
necesita recursos que no tiene actualmente.

Espere que los escépticos aporten algunos argumentos comunes, como los siguientes:

¿Qué credibilidad tiene la amenaza? Los equipos a menudo no aprecian el valor

potencial de los servicios y los datos que les han encargado proteger.
Nuestro equipo es bueno, ¿verdad? Hablar sobre un tema de seguridad puede
percibirse como una duda sobre la capacidad del equipo para crear un sistema
seguro.
No creo que sea posible. Este es un argumento común de los ingenieros junior.
Los que tienen experiencia conocen la realidad.
Nunca hemos sufrido una vulneración de seguridad. Pero, ¿cómo lo saben?
¿Cómo podrían saberlo?
Debates sin fin sobre el valor. DevSecOps es un compromiso serio que puede
percibirse como una distracción con respecto al trabajo en funciones principales.
 Aunque la inversión en seguridad se debe equilibrar con otras necesidades, no se
puede ignorar.

El cambio de mentalidad
La cultura de DevSecOps requiere un cambio importante en la mentalidad. No solo es
necesario evitar ataques y filtraciones, sino también asumirlos.

Componentes de estrategia de seguridad

Hay muchas técnicas que se pueden aplicar en la búsqueda de sistemas más seguros.

Prevención de infracciones Suposición de infracciones

Modelos de amenazas Ejercicios de juego de guerra

Revisiones de código Monitores de seguridad central

Pruebas de seguridad Pruebas de penetración de sitios en directo

Ciclo de vida del desarrollo de seguridad (SDL)

Todos los equipos ya deben haber tenido al menos algunos procedimientos claros para
evitar ataques y filtraciones. La escritura de código seguro se ha vuelto más
predeterminada y hay muchas herramientas gratuitas y comerciales para ayudar en el
análisis estático y otras funciones de pruebas de seguridad.

Sin embargo, muchos equipos carecen de una estrategia que dé por hecho que los
ataques y filtraciones del sistema son inevitables. Aceptar que se ha recibido un ataque
puede ser algo difícil de admitir, especialmente cuando surgen conflictos con los
responsables, pero esa suposición puede ayudarle a responder preguntas sobre la
seguridad por su cuenta. No hay que saberlo todo durante una situación de vulneración
de seguridad real.

Entre las preguntas comunes que hay que plantearse se incluyen:

¿Cómo se detecta un ataque?

¿Cómo responderá si hay un ataque o penetración?
¿Cómo se puede recuperar de un ataque, como cuando se hayan filtrado o
manipulado los datos?

Procedimientos clave de DevSecOps

Hay varias procedimientos comunes de DevSecOps que se aplican a prácticamente
cualquier equipo.

En primer lugar, se deben centrar en mejorar el tiempo medio de detección y el tiempo

medio de recuperación. Estos parámetros indican cuánto tiempo se tarda en detectar un
ataque y cuánto tiempo se tarda en recuperarse, respectivamente. Se puede hacer un
seguimiento a través de pruebas continuas del sitio activo de los planes de respuesta de
seguridad. Al evaluar las posibles directrices, la misión de mejorar estos parámetros se
debe tener especialmente en cuenta.

Defina un sistema de defensa en profundidad. Cuando surja un ataque, los atacantes

pueden acceder a las redes internas y a todo lo que hay dentro de ellas. Aunque sería
ideal detener a los atacantes antes de que lleguen más lejos, si se establece una directriz
en la que se asuma los ataques incitaría a los equipos a minimizar la exposición de un
atacante que ya haya entrado.

Por último, realice evaluaciones periódicas posteriores al ataque de sus procedimientos

y entornos. Una vez salvado el ataque, el equipo debe evaluar el rendimiento de las
directrices, así como su propio cumplimiento. Las directrices son más eficaces cuando
los equipos las siguen fielmente. Cada ataque, ya sea real o ejercido, debe considerarse
una oportunidad para mejorar.

Estrategias para mitigar amenazas

Hay demasiadas amenazas para nombrarlas todas. Algunas vulnerabilidades de
seguridad se deben a problemas en dependencias como sistemas operativos y
bibliotecas, por lo que mantenerlas actualizadas es crítico. Otros se deben a errores en
el código del sistema que requieren un análisis cuidadoso para encontrarlos y
corregirlos. La mala administración secreta es la causa de muchas infracciones, como la
ingeniería social. Es bueno pensar en los diferentes tipos de brechas de seguridad y lo
que significan para el sistema.

Vectores de ataque
Piense en una situación en la que un atacante ha obtenido acceso a las credenciales de
un desarrollador. ¿Qué podría hacer?

Privilege Tráfico

¿Podría enviar correos electrónicos? Amigos del phishing

¿Podría acceder a otras máquinas? Iniciar sesión, mimikatz, repetir

 Privilege Tráfico

¿Podría modificar la fuente? Insertar código

¿Podría modificar el proceso de Insertar código, ejecutar scripts

compilación o de creación de versiones?

¿Podría acceder a un entorno de prueba? Si un entorno de producción toma una dependencia

en el entorno de prueba, hay que aprovecharlo

¿Podría acceder al entorno de Son tantas las opciones...

producción?

¿Cómo puede su equipo defenderse contra estos ataques?

Almacenamiento de secretos en almacenes protegidos

Eliminación de cuentas de administrador local
Restricción de SAMR
Credential Guard
Eliminación de servidores de base dual
Suscripciones independientes
Multi-Factor Authentication
Estaciones de trabajo con privilegios de acceso
Método de detección con ATP & Microsoft Defender for Cloud

Administración de secretos
Todos los secretos se deben almacenar en un almacén protegido. Los secretos incluyen:

Contraseñas, claves y tokens

Claves de cuenta de almacenamiento
Certificados
Credenciales usadas en entornos que no son de producción compartidos también

Debe usar una jerarquía de almacenes para eliminar la duplicación de secretos. Tenga en
cuenta también cómo y cuándo se accede a los secretos. Algunos se usan en fase de
implementación al compilar configuraciones de entorno, mientras que se accede a otros
en tiempo de ejecución. Normalmente, los secretos en fase de implementación
necesitan de una nueva implementación para seleccionar la nueva configuración,
mientras que se accede a los secretos en tiempo de ejecución cuando es necesario y se
pueden actualizar en cualquier momento.

Las plataformas cuentan con funciones de almacenamiento seguras para administrar

secretos en procesos de CI/CD y entornos en la nube, como Azure Key Vault y GitHub
Actions .

Herramientas útiles
Microsoft Defender for Cloud es ideal para alertas de infraestructura genéricas,
como malware, procesos sospechosos, etc.
Herramientas de análisis de código fuente para pruebas estáticas de seguridad
de aplicaciones (SAST).
GitHub advanced security para el análisis y la supervisión de repositorios.
mimikatz extrae contraseñas, claves, códigos pin, tickets y mucho más de la
memoria de [Link] , el Servicio de subsistema de autoridad de seguridad local
en Windows. Solo se exige acceso administrativo a la máquina o una cuenta con
privilegios de depuración activados.
BloodHound crea un gráfico de las relaciones dentro de un entorno de Active
Directory. Se puede usar el equipo rojo para identificar fácilmente vectores de
ataque que son difíciles de identificar rápidamente.

Ejercicios de juego de guerra

Una práctica común en Microsoft es llevar a cabo ejercicios de juegos de guerra. Estos
son eventos de prueba de seguridad en los que dos equipos se encargan de probar la
seguridad y las directivas de un sistema.

El equipo rojo asume el rol de atacante. Intentan simular ataques reales para detectar
brechas en la seguridad. Si pueden traspasar alguna barrera, también demuestran el
posible impacto de sus ataques.

El equipo azul asume el rol del equipo de DevOps. Prueban su capacidad de detectar y
responder a los ataques del equipo rojo. Esto ayuda a mejorar el conocimiento de cada
situación y evaluar la preparación y eficacia de la estrategia de DevSecOps.

Progreso de una estrategia de juegos de guerra

Los juegos de guerra son eficaces para reforzar la seguridad porque motivan al equipo
rojo a encontrar y poner a prueba problemas. Probablemente sea mucho más fácil de lo
esperado al principio. Los equipos que no han intentado atacar activamente sus propios
sistemas no suelen tener en cuenta el tamaño y la cantidad de brechas de seguridad a
disposición de los atacantes. El equipo azul puede desmoralizarse al principio, ya que
volverán a sufrir los ataques repetidas veces. Afortunadamente, el sistema y los
procedimientos deben evolucionar con el tiempo de manera que el equipo azul pueda
salir vencedor consecuentemente.
Preparación de los juegos de guerra
Antes de comenzar los juegos de guerra, el equipo debe ocuparse de cualquier
problema que pueda encontrar a través de un pase de seguridad. Este es un gran
ejercicio para realizar antes de intentar lanzar un ataque, ya que aportará una
experiencia base para que todos los usuarios comparen con la situación después de
detectar la primera vulnerabilidad más adelante. Empiece por identificar
vulnerabilidades mediante una revisión manual del código y el uso de herramientas de
análisis estático.

Organizar equipos
Los equipos rojos y azules deben organizarse por especialidad. El objetivo es crear los
equipos más capaces en cada ámbito lado con el fin de ejecutar las operaciones lo más
eficazmente posible.

El equipo rojo debe estar formado por algunos ingenieros orientados a la seguridad y
desarrolladores que estén muy familiarizados con el código. También resulta útil integrar
en el equipo a un especialista en pruebas de penetración, si es posible. Si no hay
especialistas internos, muchas empresas prestan este servicio junto con la mentoría.

El equipo azul debe estar formado por ingenieros de operaciones que conozcan muy
bien los sistemas y registros disponibles. Estos tienen más posibilidades de detectar y
neutralizar la actividad sospechosa.

Ejecución de los primeros juegos de guerra

Se debe esperar que el equipo rojo sea efectivo en los primeros juegos de guerra.
Deben poder realizarse correctamente a través de ataques bastante simples, como
encontrar secretos mal protegidos, inserción de código SQL y campañas de
suplantación de identidad eficaces. Dedique mucho tiempo entre sesiones a aplicar
correcciones y dejar comentarios sobre las directrices. Esto puede variar según la
organización, pero no es recomendable empezar la siguiente sesión hasta que todos
estén seguros de que la anterior se ha explotado todo lo posible y aconsejable.

Desarrollo de los juegos de guerra

Tras unas sesiones, el equipo rojo tendrá que confiar en técnicas más sofisticadas, como
scripts de sitios (XSS), ataques de deserialización y vulnerabilidades del sistema de
ingeniería. La incorporación de expertos externos en seguridad en áreas como Active
Directory puede resultar útil para contrarrestar vulnerabilidades de seguridad poco
conocidas. En este punto, el equipo azul no solo debe tener una plataforma protegida
para defender, sino que también usará el registro completo y centralizado para los
análisis forenses posteriores al ataque.

“Los defensores piensan en listas. Los atacantes piensan en gráficas. Siempre que
esto se dé, los atacantes siempre ganan”. -- John Lambert (MSTIC)

Si pasa mucho tiempo, el equipo rojo tardará mucho más en alcanzar los objetivos.
Cuando lo hacen, a menudo se necesita la detección y encadenamiento de varias
vulnerabilidades para tener un impacto limitado. A través del uso de herramientas de
control en tiempo real, el equipo azul debe empezar a detectar posibles ataques en
tiempo real.

Directrices
Los juegos de guerra no deberían ser una barra libre para todos. Es importante
reconocer que el objetivo es generar un sistema más eficaz ejecutado por un equipo
más eficaz.

Código de conducta
Este es un código de conducta de ejemplo que se practica en Microsoft:

1. Los equipos rojo y azul no harán ningún daño. Si la posibilidad de causar daños es
significativa, debe documentarse y resolverse.
2. El equipo rojo no debe poner en peligro más de lo necesario para capturar los
recursos de destino.
3. Las reglas del sentido común se aplican a los ataques físicos. Aunque se anima al
equipo rojo a ser creativo con ataques no técnicos, como la ingeniería social, no
deben imprimir credenciales falsas, hostigar a las personas, etc.
4. Si un ataque de ingeniería social tiene éxito, no revele el nombre de la persona
que se ha visto involucrada. La lección se puede compartir sin alienar o avergonzar
a un miembro del equipo con el que todos los usuarios necesitan seguir
trabajando.

Reglas de juego

Estas son ejemplos de reglas del juego usadas por Microsoft:

1. No afectar a la disponibilidad de ningún sistema.

2. No acceder a datos externos del cliente.
 3. No debilitar significativamente las medidas de seguridad en ningún servicio.
4. No realizar intencionadamente intervenciones destructivas contra ningún recurso.
5. Proteger credenciales, vulnerabilidades y otra información crítica obtenida.

Resultados
Los riesgos de seguridad o las experiencias aprendidas deben documentarse en un
trabajo pendiente de elementos de reparación. Los equipos deben definir un acuerdo
de nivel de servicio (SLA) para responder a los riesgos de seguridad rápidamente. Los
riesgos graves deben subsanarse lo antes posible, mientras que los problemas menores
pueden tener un plazo límite de dos sprints.

Se debe presentar un informe a toda la organización con las experiencias aprendidas y

las vulnerabilidades detectadas. Es una oportunidad de aprendizaje para todos los
usuarios, así que hay que aprovecharlo.

Experiencias aprendidas en Microsoft

Cada cierto tiempo, Microsoft poner en marcha juegos de guerra y ha sacado muchas
conclusiones y experiencias durante todo este tiempo.

Los juegos de guerra son una manera eficaz de cambiar la cultura de DevSecOps y
tener como prioridad la seguridad.
Los ataques de suplantación de identidad (phishing) son muy eficaces para los
atacantes y no deben ser subestimados. El impacto se puede contener limitando el
acceso a la fase de producción y mediante autenticación de dos factores.
El control del sistema de ingeniería lleva a poder controlar todo. Asegúrese de
controlar estrictamente el acceso al agente de compilación o versión, la cola, el
grupo y la definición.
Practique la defensa en profundidad para que los atacantes lo tengan más difícil.
Cada barrera que tengan que sobrepasar los ralentiza y da otra oportunidad para
atraparlos.
Nunca cruce dominios de confianza. El equipo de producción nunca debe confiar
en nada en la prueba.

Pasos siguientes
Obtenga más información sobre el ciclo de vida del desarrollo de la seguridad y
DevSecOps en Azure .
Habilitación de DevSecOps con Azure y
GitHub
Artículo • 27/07/2023

DevSecOps, a veces denominado Secure DevOps, se basa en los principios de

DevOps , pero coloca la seguridad en el centro del ciclo de vida de toda la aplicación.
Este concepto se denomina “seguridad de desplazamiento a la izquierda”: traslada la
seguridad hacia arriba de una preocupación solo de producción para abarcar las
primeras fases del planeamiento y el desarrollo. Todos los equipos e individuos que
trabajan en una aplicación deben tener en cuenta la seguridad.

Microsoft y GitHub ofrecen soluciones para generar confianza en el código que se

ejecuta en producción. Estas soluciones inspeccionan el código y permiten su
trazabilidad hasta los elementos de trabajo y la información sobre los componentes de
terceros que están en uso.

Protección del código con GitHub

Los desarrolladores pueden usar herramientas de examen de código que analicen de
forma rápida y automática el código en un repositorio de GitHub para encontrar
vulnerabilidades de seguridad y errores de programación.

Puede examinar código para buscar, evaluar y priorizar las correcciones de los
problemas existentes en el código. El análisis de código también evita que los
desarrolladores generen nuevos problemas. Puede programar los análisis para días y
horas concretos, o bien desencadenarlos cuando se produzca un evento específico en el
repositorio, como una inserción. También puede realizar el seguimiento de las
dependencias del repositorio y recibir alertas de seguridad cuando GitHub detecte
dependencias vulnerables.

Análisis del código con CodeQL y el examen de tokens

Administración de avisos de seguridad para los proyectos
Protección de las dependencias del código con Dependabot

Seguimiento del trabajo con Azure Boards

Los equipos pueden usar el servicio web Azure Boards para administrar sus proyectos
de software. Azure Boards ofrece un amplio conjunto de funcionalidades, como
compatibilidad nativa con Scrum y Kanban, paneles personalizables e informes
integrados.

Planificación y seguimiento del trabajo con Azure Boards

Conexión de Azure Boards con GitHub

Compilación e implementación de
contenedores con Azure Pipelines
Integre clústeres de Azure Pipelines y Kubernetes con facilidad. Puede usar los mismos
documentos de YAML para crear canalizaciones de varias fases como código para la
integración continua y la entrega continua.

Azure Pipelines integra el seguimiento de los metadatos en las imágenes de

contenedor, incluidos los hash de confirmación y los números de emisión de Azure
Boards, lo que le permite inspeccionar las aplicaciones con confianza.

La capacidad de crear canalizaciones de implementación con archivos de YAML y

almacenarlas en el control de código fuente ayuda a impulsar un bucle de comentarios
más estrecho entre los equipos de desarrollo y operaciones que confían en documentos
claros y legibles.

Almacenamiento de imágenes de Docker en Azure Container Registry

Creación de una imagen de Docker con Azure Pipelines
Implementación en Kubernetes con rastreabilidad completa
Protección de Azure Pipelines

Ejecución y depuración de contenedores con

Bridge to Kubernetes
El desarrollo de una aplicación de Kubernetes puede ser complicado. Para ello, necesita
archivos de configuración de Docker y Kubernetes. Además, debe averiguar cómo
probar la aplicación localmente e interactuar con otros servicios dependientes. Es
posible que deba desarrollar y probar varios servicios a la vez y con un equipo de
desarrolladores.

Puente a Kubernetes le permite ejecutar y depurar el código en el equipo de desarrollo

mientras sigue conectado al clúster de Kubernetes con el resto de aplicaciones o
servicios. El código se puede probar de un extremo a otro, se pueden establecer puntos
de interrupción en el código que se ejecuta en el clúster y compartir un clúster de
desarrollo entre los miembros del equipo sin interferencias.
 Obtenga más información sobre Bridge to Kubernetes.

Exigencia de la seguridad del contenedor con

Microsoft Defender para contenedores y Azure
Policy
Microsoft Defender para contenedores es la solución nativa de nube para proteger sus
contenedores.

Introducción a Microsoft Defender para contenedores

Descripción de Azure Policy para clústeres de Kubernetes (versión preliminar)
Azure Kubernetes Service (AKS)

Administración de identidades y acceso con la

plataforma de identidad de Microsoft
La plataforma de identidad de Microsoft es la evolución de la plataforma para
desarrolladores de Azure Active Directory (Azure AD). Permite a los desarrolladores
compilar aplicaciones que inicien sesión en todas las identidades de Microsoft, obtener
tokens para llamar a las API de Microsoft, como Microsoft Graph, o a otras API que los
desarrolladores hayan creado.

Documentación de la plataforma de identidad de Microsoft

Azure AD B2C proporciona identidad de negocio a cliente como servicio. Los clientes
usan las identidades de la cuenta de redes sociales, corporativa o local preferidas para
acceder al inicio de sesión único para sus aplicaciones y API.

Documentación de Azure AD B2C

La administración de acceso de los recursos en la nube es una función esencial para

cualquier organización que use la nube. El control de acceso basado en rol de Azure
(RBAC de Azure) ayuda a administrar quién tiene acceso a los recursos de Azure, qué
pueden hacer con esos recursos y a qué áreas pueden acceder.

Obtenga más información sobre la administración de accesos con Azure RBAC

Puede usar la plataforma de identidad de Microsoft para autenticarse con el resto de las
herramientas de DevOps, incluida la compatibilidad nativa dentro de Azure DevOps e
integraciones con GitHub Enterprise.
 Autenticación en GitHub Enterprise

Actualmente, un clúster de Azure Kubernetes Service (AKS) (específicamente, el

proveedor de nube Kubernetes) requiere una identidad para crear recursos adicionales,
como equilibradores de carga y discos administrados en Azure. Esta identidad puede ser
una identidad administrada o una entidad de servicio. Si usa una entidad de servicio,
debe indicarla, o bien AKS la creará automáticamente. Si usa la identidad administrada,
AKS creará una automáticamente. En el caso de los clústeres que usan entidades de
servicio, la entidad de servicio debe renovarse finalmente para mantener el clúster en
funcionamiento. La administración de entidades de servicio agrega complejidad, por lo
que es más fácil usar identidades administradas. Se aplican los mismos requisitos de
permisos tanto en las entidades de servicio como en las identidades administradas.

Las identidades administradas son básicamente un contenedor relacionado con las

entidades de servicio y facilitan su administración.

Uso de identidades administradas en AKS

Administración de claves y secretos con Azure

Key Vault
Azure Key Vault se puede usar para almacenar de forma segura y controlar el acceso a
tokens, contraseñas, certificados, claves de API y otros secretos. La centralización del
almacenamiento de secretos de aplicación en Key Vault permite controlar su
distribución. Key Vault reduce en gran medida las posibilidades de que se puedan filtrar
por accidente los secretos. Cuando se usa Key Vault, los desarrolladores de aplicaciones
ya no necesitan almacenar información de seguridad en su aplicación, lo que elimina la
necesidad de hacer que esta información forme parte del código. Por ejemplo, puede
que una aplicación necesite conectarse a una base de datos. En lugar de almacenar la
cadena de conexión en el código de la aplicación, puede almacenarla de forma segura
en Key Vault.

Almacenamiento de certificados, claves y secretos con Azure Key Vault

Supervisión de las aplicaciones

Con Azure Monitor, puede supervisar la aplicación y la infraestructura en tiempo real, lo
que permite identificar problemas con el código, así como posibles actividades
sospechosas y anomalías. Azure Monitor se integra con las canalizaciones de versión en
Azure Pipelines para habilitar la aprobación automática de las validaciones de calidad o
la reversión de la versión en función de los datos de supervisión.
Obtenga información sobre cómo supervisar las aplicaciones y la infraestructura con
Azure Application Insights y Azure Monitor.

Administración del rendimiento de las aplicaciones con Application Insights

Supervisión de aplicaciones contenedorizadas con Azure Monitor

Creación de la arquitectura adecuada

La seguridad constituye uno de los aspectos más importantes de cualquier arquitectura.
La seguridad proporciona garantías de confidencialidad, integridad y disponibilidad
contra ataques deliberados y abuso de sus datos y sistemas valiosos. La pérdida de
estas garantías puede afectar negativamente a las operaciones comerciales y los
ingresos, así como a la reputación de su organización en Marketplace.

Arquitectura de aplicaciones y servicios

Arquitectura de DevSecOps
Eventos y charlas de DevOps
Artículo • 11/09/2023

Aspectos destacados
Introducción a Azure DevOps Metodología ágil en Microsoft

Azure DevOps Services

Vídeos y presentaciones de servicios de Azure DevOps.

Título DESCRIPCIÓN VÍDEO DESCARGAR

Introducción a Azure Planee de un modo más inteligente, colabore Vídeo PPT

DevOps mejor y distribuya sus soluciones más
rápidamente con un conjunto de servicios para
desarrolladores modernos.

Planeación del Cualquiera que haya trabajado en proyectos de Vídeo PPT

trabajo con Azure software sabe que surgen problemas a la hora
Boards de realizar el seguimiento, la administración y
la priorización. Azure Boards tiene todas las
características que su equipo necesita para
administrar correctamente el trabajo. Vea los
proyectos con paneles Kanban, ejecútelo en
sprints, administre el trabajo pendiente y use
consultas para buscar el trabajo y visualizar los
resultados. Descubra cómo empezar a usar
Azure Boards.

Administración y Si escribe código, necesita un lugar para Vídeo

almacenamiento del almacenarlo y administrarlo con un sistema de
código en Azure control de versiones fiable como Git. Azure
Repos Repos ofrece la mejor solución de Git. Tendrá
acceso a repositorios privados y públicos
 Título DESCRIPCIÓN VÍDEO DESCARGAR

gratuitos, revisiones de código sociales y

mucho más. Descubra cómo empezar a usar Git
en Azure Repos y cómo su equipo puede usar
solicitudes de incorporación de cambios para
trabajar juntos en el código.

Usar Azure Pipelines Descubra cómo usar un repositorio de GitHub Vídeo

para añadir y añadir compilaciones continuas con Azure
compilaciones Pipelines. Verá cada paso para encargarse de
continuas a un proyecto de GitHub de [Link] y añadir
proyectos de GitHub compilaciones continuas para validar la calidad
del código de cada solicitud de incorporación
de cambios. Azure Pipelines es gratuito para
proyectos de código abierto.

Compilación e Con Azure Pipelines, puede compilar e Vídeo

implementación del implementar el código escrito en cualquier
código con Azure lenguaje con cualquier plataforma. En este
Pipelines vídeo, sabrá por qué Azure Pipelines es la
mejor herramienta del planeta para la
integración continua y la implementación
continua (CI/CD) de código.

Introducción a Azure Para ayudarle a administrar los componentes Vídeo PPT

Artifacts de software, Azure Artifacts le ofrece una
interfaz de usuario intuitiva, así como
herramientas útiles para garantizar la
inmutabilidad y el rendimiento de los
componentes que crea o consume. Descubra
cómo empezar creando una fuente para un
paquete npm que se usará en Azure Pipeline.

Pruebas Test Plans de Azure DevOps proporciona todas Vídeo

automatizadas y las herramientas que necesita para ejecutar
manuales con Azure pruebas de las aplicaciones correctamente.
Test Plans Puede crear y ejecutar planes de pruebas
manuales, generar pruebas automatizadas y
recopilar comentarios de los usuarios. En este
vídeo, conocerá los aspectos básicos sobre
cómo empezar a trabajar con Azure Test Plans
para que pueda empezar a ejecutar pruebas de
su aplicación hoy mismo.

Azure DevOps Server

Presentación de Azure DevOps Server.
 Título DESCRIPCIÓN DESCARGAR

Azure Comparta código, realice un seguimiento del trabajo y envíe PPT

DevOps software mediante herramientas de desarrollo integradas,
Server hospedado en el entorno local.

Lecciones aprendidas e historias de recorridos

de Azure DevOps
Vídeos y presentaciones de lecciones aprendidas e historias de recorridos de Azure
DevOps.

Título DESCRIPCIÓN VÍDEO DESCARGAR

60 000 pruebas en Es fundamental contar con una buena Vídeo PPT

seis minutos: Crear un cobertura de pruebas para detectar
proceso de pruebas problemas antes de que se fusione mediante
fiables & e combinación una solicitud de incorporación
implementaciones de cambios, pero debe ser el tipo correcto de
seguras con Azure pruebas y debe ser confiable. Sam
Pipelines Guckenheimer explica con detalle la
transformación de las pruebas por la que su
equipo en Microsoft ha pasado a medida que
empezaron su recorrido de DevOps. Describe
los cambios que han realizado y por qué y
explica los datos encontrados con los que
fundamentaron sus motivos de cambio y lo
que hicieron para realizarlo. Sam también
detalla qué elementos se incluyen mejor en
las pruebas unitarias, cuáles debe dejar para la
revisión manual del código en la solicitud de
incorporación de cambios y cuáles son más
adecuados para las pruebas en producción.

Implementación Este informe de experiencia trata sobre la Vídeo PPT

progresiva, arquitectura de cambio desde un monolito
experimentación, hasta los procedimientos nativos de la nube.
multiinquilinos, sin Aquí se explica el traslado de escalado desde
tiempo de inactividad, un único inquilino a varios inquilinos, del
seguridad en la nube escalado vertical al escalado horizontal, de
recursos fijos a costes variables optimizados,
de actualizaciones periódicas a actualizaciones
sin tiempo de inactividad, del trabajo
acumulado único a la experimentación
continua, de implementación lineal a
progresiva con un radio de impacto
controlado, de ciclos de versiones
Título DESCRIPCIÓN VÍDEO DESCARGAR

prolongados a pruebas continuas y de

informes de seguridad de versiones
preliminares a medidas de seguridad
continuas.

DevOps para IA Dado que el campo de IA es joven en Vídeo PPT

comparación con el desarrollo de software
tradicional, los procedimientos recomendados
y las soluciones para la administración del
ciclo de vida de estos sistemas de inteligencia
artificial todavía tienen que solidificarse. En
esta charla se analizará lo que Microsoft ha
hecho en diferentes departamentos, incluido
Bing.

Evolución de Un resumen del recorrido por el que ha Vídeo PPT

Windows: El recorrido pasado Windows para transformar su proceso,
a DevOps las herramientas y la cultura l en un modelo
DevOps.

Buscar más vídeos

Azure DevOps en YouTube
Vídeos de DevOps sobre eventos de Microsoft