Aplicación de sistemas de ingeniería de software

Artículo
07/23/2024

La mejora del autoservicio de desarrollo debe ser uno de los primeros problemas que aborda en el recorrido de ingeniería de la plataforma.

Una de las formas más fáciles de empezar a habilitar experiencias automatizadas de autoservicio es reutilizar los sistemas de ingeniería existentes. No solo son estos sistemas conocidos para usted y sus clientes internos, pero pueden habilitar una amplia gama de escenarios de automatización incluso si la experiencia inicial del usuario no es bastante.

En este artículo se proporcionan sugerencias para aplicar los sistemas de ingeniería para abordar una amplia gama de escenarios de autoservicio y detalles sobre cómo encapsular los procedimientos recomendados en plantillas que le ayudarán a empezar a trabajar correctamente y a mantenerse a la derecha.

Evaluación de las prácticas base de DevOps y DevSecOps

Los sistemas de ingeniería son un aspecto crítico de la plataforma de desarrollo interna. Las plataformas de desarrollo internas se crean a partir de los inquilinos principales de DevOps y DevSecOps para reducir la carga cognitiva para todos los implicados.

DevOps combina el desarrollo y las operaciones para unir personas, procesos y tecnología en el planeamiento de aplicaciones, el desarrollo, la entrega y las operaciones. Está pensado para mejorar la colaboración en roles aislados históricamente, como el desarrollo, las operaciones de TI, la ingeniería de calidad y la seguridad. Establezca un bucle continuo entre el desarrollo, la implementación, la supervisión, la observación y los comentarios. DevSecOps capas en este bucle con prácticas de seguridad continuas en todo el proceso de desarrollo de aplicaciones.

Imagen del ciclo de vida de DevOps con plan, entrega, desarrollo y funcionamiento.

Las secciones siguientes se centran en las mejoras que se atribuyen más directamente al movimiento de ingeniería de plataforma: rutas de acceso asfaltadas, aprovisionamiento automatizado de infraestructura (además de la implementación de aplicaciones), configuración del entorno de codificación, junto con el aprovisionamiento de autoservicio y la configuración de herramientas, recursos de equipo y servicios que no forman parte directa del bucle de desarrollo de aplicaciones.

Establecer las rutas de acceso asfaltadas deseadas

Si ya tiene varios conjuntos de herramientas que componen los sistemas de ingeniería, una decisión temprana para tomar es si desea consolidarlos como parte de sus esfuerzos iniciales de ingeniería de plataforma o si va a apoyar una constelaciones de herramientas diferentes desde el principio. Definir un conjunto de rutas de acceso asfaltadas dentro de esta constelaciones de herramientas es más eficaz y proporciona un mayor nivel de flexibilidad.

A medida que empiece a cambiar hacia una mentalidad de producto, piense en los sistemas de ingeniería dentro de estas rutas de desarrollo, ya que consta de herramientas que se administran de forma centralizada como servicio a los equipos de desarrollo. Los equipos individuales o divisiones de su organización pueden desviarse, pero se espera que administren, mantengan y paguen por sus herramientas por separado, a la vez que siguen cumpliendo los requisitos de cumplimiento. Esto proporciona una manera de alimentar nuevas herramientas en el ecosistema sin interrupciones, ya que puede evaluar cualquier cosa que se desvíe para la posible inclusión en un camino asfaltado a lo largo del tiempo. Como líder de ingeniería de plataformas lo puso:

Todavía puedes hacer tu propia cosa pero hacerlo en una dirección en la que vamos... usted puede cambiar lo que quiera, pero esto se convierte en su responsabilidad. Tú eres el propietario de los cambios: posees los cuchillos afilados. - Mark, jefe de ingeniería de plataformas, Gran Empresa Multinacional Minorista Multinacional

Dado que un objetivo clave para la ingeniería de plataforma es cambiar a una mentalidad de producto en la que se proporciona valor a los clientes internos, este enfoque de constelaciones suele funcionar mejor que un mandato de arriba abajo. A medida que establece y refina las rutas de acceso asfaltadas, dejar cierta flexibilidad permite a los equipos proporcionar entradas y abordar los requisitos verdaderamente únicos para una aplicación determinada sin afectar a otros usuarios de la organización. Esto conduce a un conjunto de caminos totalmente asfaltados, dorados, mientras que otros solo están parcialmente asfaltados. En los casos en los que no haya requisitos únicos, los equipos de desarrollo de trabajo adicionales que se ocupan naturalmente harán que quieran pasar a una ruta de acceso admitida a lo largo del tiempo.

Si prefiere una estrategia de consolidación, la migración de aplicaciones existentes podría ser más trabajo de la esperada, por lo que es probable que quiera centrarse en el aspecto correcto de inicio de este espacio y centrarse en los nuevos proyectos. Esto le da su primer camino asfaltado, mientras que todo lo existente está intrínsecamente sin pintar. Los equipos de desarrollo en la ruta de acceso sin pintar considerarán la posibilidad de mover una vez que la nueva ruta de acceso asfaltada muestre su valor a la organización. En ese momento, puede ejecutar una campaña adecuada para obtener a todos los usuarios en su estado deseado a través de la comunicación bidireccional, ya que los equipos de desarrollo ven esto como una ventaja en lugar de un impuesto. Durante la campaña, los equipos de ingeniería de plataforma pueden centrarse en ayudar a los equipos a migrar, mientras que los equipos de desarrollo proporcionan comentarios sobre cómo mejorar las rutas de desarrollo.

Independientemente, evite exigir el uso de las rutas de acceso asfaltadas. La manera más eficaz de implementar rutas de acceso asfaltadas es resaltar lo que los equipos salen de ellos en lugar de a través de la adopción forzada. Puesto que su plataforma interna para desarrolladores se centra en hacer que estos mismos equipos se alegro, presupuesto y presión de tiempo a valor sobre los líderes individuales se encargan del resto. Obtenga las campañas correctas y proporcione una vía para las conversaciones bidireccionales de la mejor manera para aquellos que se encuentran en un camino sin revisión para cambiar.

Uso de las herramientas de automatización de desarrolladores para mejorar el autoservicio de las rutas de acceso asfaltadas

Parte de la creación de su primera ruta de acceso asfaltada debe ser establecer sus productos principales de automatización de desarrolladores. Estos son importantes a medida que empiece a pensar en habilitar las funcionalidades de autoservicio del desarrollador.

Habilitación del aprovisionamiento automático de la infraestructura de aplicaciones durante la entrega continua

Si aún no se ha implementado, es probable que los problemas identificados durante la planeación apunten a problemas que la integración continua (CI) y la entrega continua (CD) pueden ayudar a resolver. En este espacio existen productos como Acciones de GitHub, Azure DevOps, Jenkins, junto con soluciones de GitOps basadas en extracción, como Flux o Argo CD . Puede empezar a trabajar en estos temas en el Centro de recursos de Microsoft DevOps.

Incluso si ya ha implementado una manera de implementar continuamente la aplicación en la infraestructura existente, debe considerar la posibilidad de usar la infraestructura como código (IaC) para crear o actualizar la infraestructura de aplicaciones necesaria como parte de la canalización de CD.

Por ejemplo, considere estas ilustraciones que muestran dos enfoques que usan Acciones de GitHub para actualizar la infraestructura e implementar en Azure Kubernetes Service: uno mediante implementaciones basadas en inserción y una implementación basada en extracción (GitOps).

Lo que elija está controlado por el conjunto de aptitudes de IaC existente y los detalles de la plataforma de aplicación de destino. El enfoque de GitOps es más reciente y es popular entre las organizaciones que usan Kubernetes como base para sus aplicaciones, mientras que el modelo basado en extracción ofrece actualmente la mayor flexibilidad dada la cantidad de opciones disponibles para ella. Esperamos que la mayoría de las organizaciones usen una combinación de las dos. Independientemente de que se conviertan bien en prácticas de IaC le ayudarán a aprender patrones que se aplican a escenarios de automatización adicionales.

Centralización de IaC en un catálogo o registro para escalar y mejorar la seguridad

Para administrar y escalar IaC entre aplicaciones, debe publicar los artefactos de IaC de forma centralizada para su reutilización. Por ejemplo, puede usar módulos de Terraform en un registro, módulos de Bicep, recetas de Radius o gráficos de Helm almacenados en un registro de artefactos de OCI nativo en la nube, como Azure Container Registry (ACR), DockerHub o el catálogo en Entornos de implementación de Azure (ADE). En el caso de GitOps y Kubernetes, la API de clúster (e implementaciones como CAPZ) puede permitirle administrar clústeres de cargas de trabajo de Kubernetes, mientras que las definiciones de recursos personalizados, como El operador de servicio de Azure, pueden proporcionar compatibilidad agregada con otros tipos de recursos de Azure, otras herramientas como recursos de soporte técnico entre planos en varias nubes. Estos permiten usar gráficos de Helm centralizados o comunes en algo parecido a ACR para una amplia variedad de escenarios.

La centralización de IaC mejora la seguridad al proporcionarle un mejor control sobre quién puede realizar actualizaciones, ya que ya no se almacenan con código de aplicación. Hay menos riesgo de una interrupción accidental causada por un cambio accidental durante una actualización de código cuando expertos, operaciones o ingenieros de plataforma realizan cambios necesarios. Los desarrolladores también se benefician de estos bloques de creación, ya que no tienen que crear plantillas de IaC completas y beneficiarse automáticamente de los procedimientos recomendados codificados.

El formato iaC que elija dependerá del conjunto de aptitudes existente, del nivel de control que necesite y del modelo de aplicación que use. Por ejemplo , Azure Container Apps (ACA) y el reciente proyecto experimental de incubación del sistema operativo Radius OSS se opinan más que usar Kubernetes directamente, pero también simplifican la experiencia del desarrollador. El módulo describir tipos de servicio en la nube puede ayudarle a comprender las ventajas y desventajas de diferentes modelos. Independientemente de que haga referencia a IaC centralizada y administrada, en lugar de tener definiciones completas en el árbol de origen, tiene ventajas significativas.

Conservar las identidades o secretos de aprovisionamiento necesarios de forma que los desarrolladores no puedan acceder directamente a las capas de los bloques de creación básicos para la gobernanza. Por ejemplo, considere esta ilustración sobre la separación de roles que puede lograr mediante entornos de implementación de Azure (ADE).

Aquí, los ingenieros de plataforma y otros especialistas desarrollan IaC y otras plantillas y los colocan en un catálogo. Después, las operaciones pueden agregar identidades administradas y suscripciones por "tipo de entorno" y asignar desarrolladores y otros usuarios que puedan usarlos para el aprovisionamiento.

Los desarrolladores o la canalización de CI/CD pueden usar la CLI de Azure o la CLI para desarrolladores de Azure para aprovisionar la infraestructura preconfigurada y controlada sin tener acceso a la suscripción subyacente o a las identidades necesarias para hacerlo. Tanto si usa algo como ADE como si no, el sistema de entrega continua que prefiera puede ayudarle a actualizar la infraestructura de forma segura y segura mediante la separación de secretos y el suministro de contenido de IaC de ubicaciones a las que los desarrolladores no pueden acceder ni modificar por sí mismos.

Habilitación del autoservicio en escenarios más allá de la entrega continua de aplicaciones

Aunque los conceptos de CI y CD están vinculados al desarrollo de aplicaciones, muchas de las cosas que los clientes internos quieren aprovisionar no se vinculan directamente a una aplicación determinada. Se puede compartir la infraestructura, crear un repositorio, herramientas de aprovisionamiento, etc.

Para comprender dónde puede ayudar esto, piense en dónde tiene procesos manuales o basados en el departamento de servicio. Para cada uno, piense en estas preguntas:

¿Con qué frecuencia se produce este proceso?
¿El proceso es lento, propenso a errores o requiere un trabajo significativo para lograr?
¿Estos procesos son manuales debido a un paso de aprobación necesario o simplemente falta de automatización?
¿Los aprobadores están familiarizados con los sistemas de control de código fuente y los procesos de solicitud de incorporación de cambios?
¿Cuáles son los requisitos de auditoría para los procesos? ¿Difieren de los requisitos de auditoría del sistema de control de código fuente?
¿Hay procesos con los que puede empezar con un menor riesgo antes de pasar a otros más complejos?

Identifique los procesos frecuentes, de alto esfuerzo o propensos a errores como destinos potenciales para automatizar primero.

Usar todo como patrón de código

Una de las cosas interesantes de Git además de su ubicuidad es que está pensada para ser una fuente segura y auditable de información. Además del historial de confirmaciones y los controles de acceso, los conceptos como las solicitudes de incorporación de cambios y la protección de ramas proporcionan una manera de establecer revisores específicos, un historial de conversaciones y comprobaciones automatizadas que deben pasar antes de combinarse en la rama principal. Cuando se combina con motores de tareas flexibles como los que se encuentran en los sistemas de CI/CD, tiene un marco de automatización seguro.

La idea detrás de todo como código es que puede convertir casi cualquier cosa en un archivo en un repositorio git seguro. Después, las distintas herramientas o agentes conectados al repositorio pueden leer el contenido. Tratar todo como código ayuda a la repetibilidad a través de plantillas y simplifica el autoservicio del desarrollador. Veamos varios ejemplos de cómo puede funcionar esto.

Aplicación de patrones de IaC a cualquier infraestructura

Aunque IaC ganó popularidad para ayudar a automatizar la entrega de aplicaciones, el patrón se extiende a cualquier infraestructura, herramientas o servicios que quiera aprovisionar y configurar, no solo los vinculados a una aplicación específica. Por ejemplo, los K8 compartidos con clústeres con Flux instalados, aprovisionando algo como DataDog que usan varios equipos y aplicaciones, o incluso configurando sus herramientas de colaboración favoritas.

La forma en que funciona es que tiene un repositorio centralizado independiente protegido que alberga una serie de archivos que representan lo que se debe aprovisionar y configurar (en este caso, cualquier cosa de Bicep, Terraform, a gráficos de Helm y otros formatos nativos de Kubernetes). Un equipo de operaciones u otro conjunto de administradores propietarios del repositorio, y los desarrolladores (o sistemas) pueden enviar solicitudes de incorporación de cambios. Una vez que estos administradores combinan estas solicitudes de incorporación de cambios en la rama principal, las mismas herramientas de CI/CD que se usan durante el desarrollo de aplicaciones pueden iniciarse para procesar los cambios. Tenga en cuenta esta ilustración que usa Acciones de GitHub e identidades de implementación hospedadas en entornos de implementación de Azure:

Si ya usa un enfoque de GitOps para la implementación de aplicaciones, también puede reutilizar estas herramientas. La combinación de herramientas como Flux y el operador de servicios de Azure le permite expandirse fuera de Kubernetes:

En cualquier caso, tiene un origen de información totalmente administrado, reproducible y auditable, incluso si lo que se genera no es para una aplicación. Al igual que con el desarrollo de aplicaciones, los secretos o identidades administradas que necesita se almacenan en el motor de canalización o flujo de trabajo o en las funcionalidades nativas de un servicio de aprovisionamiento.

Dado que las personas que realizan las solicitudes de incorporación de cambios no tendrán acceso directo a estos secretos, proporciona una manera de que los desarrolladores inicien acciones de forma segura que no tengan permiso directo para hacerlo. Esto le permite cumplir el principio de privilegios mínimos al mismo tiempo que proporciona a los desarrolladores una opción de autoservicio.

Seguimiento de la infraestructura aprovisionada

A medida que empiece a escalar este enfoque, piense en cómo desea realizar un seguimiento de la infraestructura aprovisionada. El repositorio git es un origen de verdad para la configuración, pero no le indica los URI específicos y la información de estado sobre lo que creó. Sin embargo, seguir todo como enfoque de código proporciona una fuente de información para aprovechar para sintetizar un inventario de la infraestructura aprovisionada. El aprovisionamiento también puede ser una buena fuente de esta información en la que puede acceder. Por ejemplo, Los entornos de implementación de Azure incluyen funcionalidades de seguimiento del entorno en las que los desarrolladores tienen visibilidad.

Para más información sobre el seguimiento en varios orígenes de datos, consulte Diseño de una base de autoservicio para desarrolladores.

Aplicar la seguridad como código y directiva como patrones de código

Aunque la infraestructura de aprovisionamiento es útil, asegúrese de que estos entornos son seguros y, por lo general, seguir las directivas de su organización es igualmente importante. Esto ha provocado el aumento del concepto de "directiva como código". Aquí, los archivos de configuración de un repositorio de control de código fuente se pueden usar para hacer cosas como controlar la seguridad o aplicar directivas de infraestructura.

Muchos productos y proyectos código abierto diferentes han adoptado este enfoque, como Azure Policy, Open Policy Agent, GitHub Advanced Security y GitHub CODEOWNERS, entre otros. Al seleccionar la infraestructura de la aplicación, los servicios o las herramientas, asegúrese de evaluar el nivel de compatibilidad con estos patrones. Para más información sobre cómo refinar la aplicación y la gobernanza, consulte Refinar la plataforma de aplicaciones.

Usar todo como código para sus propios escenarios

Todo como código amplía estos patrones a una amplia variedad de tareas de automatización y configuración más allá de IaC. Puede admitir no solo la creación o configuración de cualquier tipo de infraestructura, sino también la actualización de datos o la activación de flujos de trabajo en cualquier sistema de bajada.

La solicitud de incorporación de cambios se convierte en una buena experiencia de usuario de autoservicio de línea base para varios procesos diferentes, especialmente cuando se está iniciando. Los procesos obtienen naturalmente las ventajas de seguridad, auditoría y reversión que ofrece Git, y los sistemas implicados también pueden cambiar con el tiempo sin afectar a la experiencia del usuario.

Teams como código

Un ejemplo de cómo aplicar todo como código a sus propios escenarios es el modelo de código de los equipos. Las organizaciones aplican este patrón para estandarizar la pertenencia a equipos y, en algunos casos, los derechos de herramientas y servicios de desarrollador en una amplia variedad de sistemas. Este patrón elimina los procesos manuales de incorporación y retirada del departamento de servicios impulsados por la necesidad de que los desarrolladores y operadores de sistemas accedan a sus propios conceptos de agrupación, usuario y acceso. Los procesos manuales de los servicios de servicio son un riesgo de seguridad potencial porque es posible sobreaprovisionar el acceso. Al usar los equipos como patrón de código, la combinación de solicitudes de incorporación de cambios y git puede habilitar el autoservicio desde un origen de datos auditable.

Para obtener un ejemplo de una variación madura y extensa de este patrón, consulte la entrada de blog de GitHub sobre cómo administran derechos. GitHub también ha abierto su sofisticada implementación de derechos para probar o adoptar. Aunque en la entrada de blog se describen los derechos de todos los empleados, puede aplicar los equipos como concepto de código a escenarios de equipo de desarrollo con un ámbito más limitado. Es posible que estos equipos de desarrollo no se representen en un organigrama de empleados y impliquen herramientas o servicios propietarios que puedan complicar la incorporación o retirada de los miembros del equipo.

Este es un resumen de una variación simplificada de esta idea que usa un sistema ci/CD y grupos de proveedores de identidades para coordinar las actualizaciones:

En este ejemplo:

Cada sistema implicado se ha configurado para usar el proveedor de identidades (por ejemplo, Microsoft Entra ID) para el inicio de sesión único (SSO).
Usará grupos de proveedores de identidades (por ejemplo, Grupos Entra) entre sistemas para administrar la pertenencia por rol para reducir la complejidad y mantener la auditoría centralizada.

En un nivel alto, este es el funcionamiento de este patrón:

Un repositorio git central bloqueado tiene un conjunto de archivos (normalmente YAML) en él que representan a cada equipo abstracto, pertenencia a usuarios relacionados y roles de usuario. Los propietarios o aprobadores de los cambios de equipo también se pueden almacenar en este mismo lugar (por ejemplo, a través de CODEOWNERS). La referencia a un usuario de estos archivos es el proveedor de identidades, pero este repositorio actúa como origen de verdad para estos equipos (pero no para los usuarios).
Todas las actualizaciones de estos archivos se realizan a través de solicitudes de incorporación de cambios. Esto vincula las conversaciones y los participantes relacionados en la solicitud a git commit para la auditabilidad.
Los clientes potenciales y usuarios individuales pueden hacer que las solicitudes de incorporación y eliminación de personas, y los clientes potenciales de desarrollo y otros roles pueden crear nuevos equipos mediante solicitudes de incorporación de cambios que con un nuevo archivo de equipo de una plantilla.
Cada vez que una solicitud de incorporación de cambios se combina en main, un sistema de CI/CD vinculado al repositorio actualiza el sistema del proveedor de identidades y todos los sistemas de bajada según corresponda.

En concreto, el sistema CI/CD:

Usa la API del sistema del proveedor de identidades adecuada para crear o actualizar un grupo de proveedores de identidades por rol con exactamente las personas del archivo (más, no menos).
Usa las API de cada sistema de bajada para vincular ese concepto de agrupación de sistemas a un grupo de proveedores para cada rol (ejemplo: GitHub y Azure DevOps). Esto podría dar lugar a una relación de uno a varios entre el equipo y el sistema de bajada para representar un rol.
(Opcionalmente) Usa api para cada sistema de bajada para implementar la lógica de permisos vinculada al mecanismo de agrupación del sistema.
Usa una API para actualizar un almacén de datos bloqueado con los resultados (incluida la asociación de los identificadores de equipo del sistema de bajada) que luego se pueden consumir para cualquiera de los sistemas creados internamente. También puede almacenar asociaciones para diferentes representaciones del sistema de identificadores de usuario para el mismo usuario o cuenta del proveedor de identidades aquí si es necesario.

Si su organización ya usa algo como Entra Entitlement Management, es posible que pueda omitir la administración de la pertenencia a grupos de este patrón.

Sus necesidades y directivas pueden cambiar los detalles, pero el patrón general se puede adaptar a cualquier número de variaciones. Los secretos necesarios para integrarse con cualquier sistema de bajada se mantienen en el sistema de CI/CD (por ejemplo, en Acciones de GitHub,Azure Pipelines) o en algo parecido a Azure Key Vault.

Uso de flujos de trabajo con parámetros manuales o desencadenados externamente

Es posible que algunos de los problemas relacionados con el autoservicio que identifique no sean favorables al uso de archivos en Git. O bien, es posible que tenga una interfaz de usuario que quiera usar para impulsar la experiencia de autoservicio.

Afortunadamente, la mayoría de los sistemas de CI, como Acciones de GitHub y Azure Pipelines, tienen la capacidad de configurar un flujo de trabajo con entradas que puede desencadenar manualmente a través de sus INTERFACES de usuario o CLIs. Dados los desarrolladores y los roles de operaciones relacionados probablemente ya están familiarizados con estas experiencias de usuario, los desencadenadores manuales pueden aumentar todo como patrón de código para habilitar la automatización de actividades (o trabajos) que no tienen una representación de archivo natural o que deben automatizarse completamente sin necesidad de un proceso de pr.

El sistema de CI puede permitirle optar por desencadenar estos flujos de trabajo o canalizaciones desde sus propias experiencias de usuario a través de una API. Para Acciones de GitHub, la clave para realizar este trabajo es la API REST Actions para desencadenar un evento de envío de flujo de trabajo para desencadenar una ejecución de flujo de trabajo. Los desencadenadores de Azure DevOps son similares y también puede usar la API de canalización de Azure DevOps para ejecuciones. Es probable que vea las mismas funcionalidades en otros productos. Tanto si se desencadena manualmente como a través de una API, cada flujo de trabajo puede admitir un conjunto de entradas agregando una configuración de workflow_dispatch al archivo YAML de flujo de trabajo. Por ejemplo, este es el modo en que los kits de herramientas del portal como Backstage.io interactúan con Acciones de GitHub.

Sin duda, el flujo de trabajo o el sistema de trabajo del sistema de CI/CD realiza un seguimiento de las actividades, notifica el estado y tiene registros detallados que los equipos de operaciones y desarrolladores pueden usar para ver lo que ha ido mal. De este modo, tiene algunas de las mismas ventajas de seguridad, auditoría y visibilidad que todo como patrón de código. Sin embargo, una cosa que hay que tener en cuenta es que las acciones realizadas por estos flujos de trabajo o canalizaciones tienen un aspecto similar a una identidad del sistema (por ejemplo, una entidad de servicio o una identidad administrada en Microsoft Entra ID) a sistemas de bajada.

Tendrá visibilidad sobre quién inicia solicitudes en el sistema ci/CD, pero debe evaluar si esta información es suficiente y asegurarse de que la configuración de retención de CI/CD cumple con los requisitos de auditoría para los casos en los que esta información es crítica.

En otros casos, las herramientas con las que se integra podrían tener sus propios mecanismos de seguimiento en los que puede confiar. Por ejemplo, estas herramientas de CI/CD casi siempre tienen varios mecanismos de notificación disponibles, como el uso de un canal de Microsoft Teams o Slack , que puede permitirle mantener a cualquier persona que envíe una solicitud para obtener actualizaciones de estado y el canal proporciona un registro informal de lo que ha ocurrido. Estos mismos motores de flujos de trabajo a menudo están diseñados para integrarse con herramientas de operaciones para ampliar aún más la utilidad de estos patrones.

En resumen, puede implementar cierta automatización mediante archivos almacenados en un repositorio de control de código fuente gracias a la flexibilidad de las herramientas de CI/CD y sus experiencias de usuario integradas. Para ver cómo las plataformas de desarrollo internas pueden usar este enfoque como punto de partida sin poner en peligro las funcionalidades más sofisticadas a lo largo del tiempo, consulte Diseño de una base de autoservicio para desarrolladores.

Automatización de la configuración de entornos de codificación de desarrolladores

Otro problema común en los sistemas de ingeniería es el arranque y la normalización del entorno de codificación para desarrolladores. Estos son algunos de los problemas comunes que puede conocer en esta área:

En algunos casos, un desarrollador puede tardar semanas en llegar a su primera solicitud de incorporación de cambios. Se trata de un área problemática cuando transfiere desarrolladores entre equipos de características y proyectos con bastante frecuencia (por ejemplo, en organizaciones matrices), necesitan aumentar los contratistas o están en un equipo que se encuentre en una fase de contratación.
La incoherencia entre los desarrolladores y los sistemas de CI puede provocar problemas frecuentes de "funciona en mi máquina", incluso para los miembros del equipo experimentados.
La experimentación y actualización de marcos, los tiempos de ejecución y otro software también pueden interrumpir los entornos de desarrollador existentes y provocar la pérdida de tiempo intentando averiguar exactamente lo que salió mal.
En el caso de los clientes potenciales de desarrollo, las revisiones de código pueden ralentizar el desarrollo, ya que pueden requerir un cambio de configuración para probarlos y deshacerlos una vez finalizada la revisión.
Los miembros del equipo y los operadores también tienen que dedicar tiempo a aumentar los roles relacionados más allá del desarrollo (operadores, QA, negocios, patrocinadores) para ayudar a probar, ver el progreso, entrenar roles empresariales y evangelizar el trabajo que está haciendo el equipo.

Parte de sus caminos asfaltados

Para ayudar a resolver estos problemas, piense en la configuración de herramientas y utilidades específicas como parte de sus rutas de acceso bien definidas. La configuración de la máquina del desarrollador de scripting puede ayudar y puede reutilizar estos mismos scripts en el entorno de CI. Sin embargo, considere la posibilidad de admitir entornos de desarrollo en contenedores o virtualizados debido a las ventajas que pueden proporcionar. Estos entornos de codificación se pueden configurar de antemano en las especificaciones del proyecto o de la organización.

Reemplazo de estación de trabajo y destino de Windows

Si tiene como destino Windows o quiere realizar la virtualización completa de la estación de trabajo (herramientas de cliente y configuración del sistema operativo host además de la configuración específica del proyecto), las máquinas virtuales suelen proporcionar la mejor funcionalidad. Estos entornos pueden ser útiles para cualquier cosa, desde el desarrollo de cliente de Windows al servicio de Windows o la administración y el mantenimiento de aplicaciones web de .NET full Framework.

Enfoque	Ejemplos
Uso de máquinas virtuales hospedadas en la nube	Microsoft Dev Box es una opción completa de virtualización de estación de trabajo de Windows con integración integrada en el software de administración de escritorios.
Uso de máquinas virtuales locales	Hashicorp Vagrant es una buena opción y puede usar HashiCorp Packer para compilar imágenes de máquina virtual tanto para él como para Dev Box.

Virtualización del área de trabajo y destino de Linux

Si tiene como destino Linux, considere la posibilidad de una opción de virtualización del área de trabajo. Estas opciones se centran menos en reemplazar el escritorio para desarrolladores y mucho más en áreas de trabajo específicas de proyecto o aplicación.

Enfoque	Ejemplos
Uso de contenedores hospedados en la nube	GitHub Codespaces es un entorno basado en la nube para contenedores de desarrollo que admite la integración con VS Code, IntelliJ de JetBrains y herramientas basadas en terminales. Si este o un servicio similar no satisface sus necesidades, puede usar la compatibilidad de túneles SSH o remotos de VS Code con contenedores de desarrollo en máquinas virtuales Linux remotas. La opción basada en túnel que no solo funciona con el cliente, sino con el vscode.dev basado en web.
Uso de contenedores locales	Si prefiere una opción local de contenedores de desarrollo en su lugar o además de una hospedada en la nube, los contenedores de desarrollo tienen una compatibilidad sólida en VS Code, compatibilidad con IntelliJ y otras herramientas y servicios.
Uso de máquinas virtuales hospedadas en la nube	Si encuentra contenedores demasiado limitados, la compatibilidad con SSH en herramientas como VS Code o JetBrains, como IntelliJ, le permite conectarse directamente a las máquinas virtuales Linux que administra usted mismo. VS Code también tiene una opción basada en túneles que funciona aquí.
Uso del Subsistema de Windows para Linux	Si los desarrolladores están exclusivamente en Windows, Subsistema de Windows para Linux (WSL) es una excelente manera de que los desarrolladores se dirijan a Linux localmente. Puede exportar una distribución de WSL para su equipo y compartirla con todo configurado. Para una opción de nube, los servicios de estación de trabajo en la nube, como Microsoft Dev Box, también pueden aprovechar WSL para el desarrollo de Linux como destino.

Creación de plantillas de aplicación correctas de inicio que incluyen mantener la configuración correcta

Lo mejor de todo como patrón de código es que puede mantener a los desarrolladores en las rutas de acceso asfaltadas que ha establecido desde el principio. Si se trata de un desafío para su organización, las plantillas de aplicación pueden convertirse rápidamente en una manera crítica de reutilizar los bloques de creación para impulsar la coherencia, promover la estandarización y codificar los procedimientos recomendados de su organización.

Para empezar, puede usar algo tan sencillo como un repositorio de plantillas de GitHub, pero si su organización sigue un patrón monorepo , esto podría ser menos eficaz. También puede crear plantillas que ayuden a configurar algo que no esté directamente relacionado con un árbol de origen de la aplicación. En su lugar, puede usar un motor de plantillas como cookiecutter, Yeoman o algo parecido a la CLI para desarrolladores de Azure (azd) que, además de plantillas y configuración simplificada de CI/CD, también proporciona un conjunto práctico de comandos para desarrolladores. Dado que la CLI para desarrolladores de Azure se puede usar para impulsar la configuración del entorno en todos los escenarios, se integra con los entornos de implementación de Azure para proporcionar una seguridad mejorada, iaC integrada, seguimiento del entorno, separación de problemas y configuración simplificada de CD.

Una vez que tenga un conjunto de plantillas, los clientes potenciales de desarrollo pueden usar estas herramientas de línea de comandos u otras experiencias de usuario integradas para aplicar scaffolding a su contenido para sus aplicaciones. Sin embargo, dado que es posible que los desarrolladores no tengan permiso para crear repositorios u otro contenido a partir de las plantillas, también es otra oportunidad de usar flujos de trabajo o canalizaciones desencadenados manualmente y con parámetros. Puede configurar entradas para que el sistema de CI/CD cree cualquier cosa desde un repositorio hasta la infraestructura en su nombre.

Mantenerse bien y llegar a la derecha

Sin embargo, para ayudar a escalar, estas plantillas de aplicación deben hacer referencia a bloques de creación centralizados siempre que sea posible (por ejemplo, plantillas de IaC o incluso flujos de trabajo o canalizaciones de CI/CD). De hecho, tratar estos bloques de creación centralizados como su propia forma de plantillas adecuadas de inicio podría ser una estrategia eficaz para resolver algunos de los problemas que ha identificado.

Cada una de estas plantillas individuales se puede aplicar no solo a las nuevas aplicaciones, sino también a las existentes que pretende actualizar como parte de una campaña adecuada para implementar directrices actualizadas o mejoradas. Aún mejor, esta centralización le ayuda a mantener las aplicaciones nuevas y existentes a la derecha, lo que le permite evolucionar o ampliar los procedimientos recomendados a lo largo del tiempo.

Contenido de la plantilla

Se recomienda tener en cuenta las siguientes áreas al crear plantillas.

Área	Detalles
Código fuente de ejemplo suficiente para controlar patrones de aplicación, SDK y uso de herramientas	Incluya código y configuración para dirigir a los desarrolladores hacia lenguajes recomendados, modelos y servicios de aplicaciones, API, SDK y patrones arquitectónicos. Asegúrese de incluir código para el seguimiento distribuido, el registro y la observabilidad mediante las herramientas que prefiera.
Scripts de compilación e implementación	Proporcione a los desarrolladores una manera común de desencadenar una compilación y una implementación local o de espacio aislado. Incluya la configuración de depuración en IDE o editor para las herramientas que prefiera para usarlas. Esta es una manera importante de evitar dolores de cabeza de mantenimiento y evitar que CI/CD no esté sincronizada. Si el motor de plantillas se considera como la CLI para desarrolladores de Azure, es posible que ya haya comandos que solo puede usar.
Configuración de CI/CD	Proporcione flujos de trabajo o canalizaciones para compilar e implementar aplicaciones en función de las recomendaciones. Aproveche los flujos de trabajo o canalizaciones centralizados, reutilizables o con plantilla para ayudarles a mantenerlos actualizados. De hecho, estos flujos de trabajo o canalizaciones reutilizables pueden iniciar plantillas adecuadas propias. Asegúrese de considerar una opción para desencadenar manualmente estos flujos de trabajo.
Infraestructura como recursos de código	Proporcione configuraciones de IaC recomendadas, incluidas las referencias a módulos administrados centralmente o elementos de catálogo para asegurarse de que cualquier configuración de infraestructura sigue los procedimientos recomendados desde el punto de partida. Estas referencias también pueden ayudar a los equipos a mantener el tiempo correcto a medida que avanza el tiempo. En combinación con flujos de trabajo o canalizaciones, también puede incluir IaC o EaC para aprovisionar casi cualquier cosa.
Seguridad y directiva como recursos de código	El movimiento de DevSecOps movió la configuración de seguridad al código, que es excelente para las plantillas. Algunas directivas como artefactos de código también se pueden aplicar en el nivel de aplicación. Incluya como todo, desde archivos como CODEOWNERS hasta la configuración de análisis como dependabot.yaml en GitHub Advanced Security. Proporcione flujos de trabajo programados o ejecuciones de canalización para exámenes con algo parecido a Defender for Cloud junto con ejecuciones de pruebas de entorno. Esto es importante para la seguridad de la cadena de suministro y asegúrese de tener en cuenta las imágenes de contenedor además de los paquetes de aplicación y el código. Estos pasos ayudan a los equipos de desarrollo a mantenerse correctamente.
Observabilidad, supervisión y registro	Parte de la habilitación del autoservicio proporciona visibilidad sencilla de las aplicaciones una vez implementadas. Más allá de la infraestructura en tiempo de ejecución, asegúrese de incluir la configuración para la observabilidad y la supervisión. En la mayoría de los casos, hay un aspecto de IaC para configurar (por ejemplo, implementación del agente, instrumentación) mientras que en otros podría ser otro tipo de artefacto de código de configuración como (por ejemplo, supervisar paneles para App de Azure lication Insights). Por último, asegúrese de incluir código de ejemplo de código para el seguimiento distribuido, el registro y la observabilidad mediante las herramientas que prefiera.
Configuración del entorno de codificación	Incluya archivos de configuración para codificar linters, formateadores, editores e IDE. Incluya scripts de instalación junto con archivos de virtualización de área de trabajo o estación de trabajo, como devcontainer.json, devbox.yaml, dockerfiles centrados en desarrolladores, archivos docker Compose o vagrantfiles.
Configuración de prueba	Proporcione archivos de configuración para pruebas unitarias y más detalladas mediante sus servicios preferidos, como Microsoft Playwright Testing for UI o Azure Load Testing.
Configuración de la herramienta de colaboración	Si el sistema de administración de problemas y administración de control de código fuente admite plantillas de tareas, problemas o pr como código, incluya también estas opciones. En los casos en los que se requiere más configuración, puede proporcionar opcionalmente un flujo de trabajo o canalización que actualice los sistemas mediante una CLI o API disponible. Esto también le permite configurar otras herramientas de colaboración como Microsoft Teams o Slack.