Aplicación de sistemas de ingeniería de software

La mejora del autoservicio para desarrolladores debe ser uno de los primeros problemas que aborde en su viaje de ingeniería de plataformas.

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 por usted y sus clientes internos, sino que pueden habilitar una amplia variedad de escenarios de automatización, incluso si la experiencia inicial del usuario no es muy atractiva.

En este artículo se proporcionan sugerencias para aplicar sus sistemas de ingeniería para abordar una amplia gama de escenarios de autoservicio y detalles sobre cómo encapsular las mejores prácticas en las plantillas que le ayudarán a empezar correctamente y mantenerse en el camino correcto.

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 principios principales de DevOps y DevSecOps, reduciendo la carga cognitiva para todos los involucrados.

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 se integra en este ciclo con prácticas de seguridad continuas en todo el proceso de desarrollo de aplicaciones.

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 comienzas a cambiar hacia una mentalidad de producto, piensa en los sistemas de ingeniería dentro de estos caminos trazados como consistentes de herramientas que se administran de forma centralizada como servicio para 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 integrar nuevas herramientas en el ecosistema sin interrupciones, ya que puede evaluar cualquier cosa que se desvíe para su posible inclusión en un proceso establecido con el tiempo. Como lo expresó un líder de ingeniería de plataformas:

Todavía puedes seguir tu propio camino, pero hazlo en una dirección hacia la que estamos yendo. 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, líder de ingeniería de plataformas, gran empresa minorista multinacional europea

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 aportar comentarios y abordar los requisitos verdaderamente únicos de una aplicación en concreto sin afectar a otros en 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 hay requisitos únicos, el trabajo adicional que los equipos realizan naturalmente los motiva a querer pasar a un camino respaldado con el tiempo.

Si prefiere una estrategia de consolidación, la migración de aplicaciones existentes podría ser más trabajo de lo esperado, por lo que es probable que quiera enfocarse correctamente en el inicio de este proceso y enfocar su atención en nuevos proyectos. Esto proporciona su primera ruta de acceso asfaltada, mientras que todo lo existente está intrínsecamente sin pavimentar. Los equipos de desarrollo en el camino sin pavimentar pueden considerar la posibilidad de moverse una vez que tu nuevo camino pavimentado 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 pavimentadas.

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 obtienen de ellas en lugar de fomentar la adopción forzada. Debido a que su plataforma interna para desarrolladores se centra en hacer felices a estos mismos equipos, la presión sobre el presupuesto y el tiempo para generar valor recae en los líderes individuales, quienes se encargan del resto. Consiga las campañas adecuadas y proporcione una vía para conversaciones bidireccionales sobre la mejor manera para que aquellos que se encuentran en un camino sin pavimentar puedan migrar.

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 primer camino pavimentado debe ser establecer sus productos de automatización para 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, los problemas identificados durante el planeamiento probablemente 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 las siguientes ilustraciones que muestran dos enfoques que usan Acciones de GitHub para actualizar la infraestructura e implementar en Azure Kubernetes Service: una 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. De todos modos, familiarizarse bien con las prácticas de IaC le ayudará 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 nativo de la nube para artefactos de OCI, como Azure Container Registry (ACR),DockerHub o el catálogo en Azure Deployment Environments (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 Azure Service Operator , pueden ofrecer compatibilidad agregada con otros tipos de recursos de Azure. Otras herramientas, como crossplane , admiten recursos 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 de software de código abierto Radius son más estructurados que usar Kubernetes directamente, pero también simplifican la experiencia de desarrollador. Para obtener información sobre las ventajas y desventajas de diferentes modelos, consulte Descripción de los tipos de servicio en la nube. 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 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, conceptos como los pull requests y la protección de ramas proporcionan una manera de establecer revisores específicos, un historial de discusiones, y comprobaciones automatizadas que deben pasar antes de fusionarse 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 de 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 clústeres de Kubernetes compartidos con Flux instalados, el aprovisionamiento de algo como DataDog que usan varios equipos y aplicaciones, o incluso configurar 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 o Terraform, a gráficos de Helm y otros formatos nativos de Kubernetes). Un equipo de operaciones u otro conjunto de administradores son responsables del repositorio, y los desarrolladores (o sistemas) pueden enviar solicitudes de incorporación de cambios (PRs). Una vez que estos administradores fusionan estas pull requests en la rama principal, pueden iniciarse las mismas herramientas de CI/CD que se utilizan durante el desarrollo de aplicaciones para procesar los cambios. Tenga en cuenta la siguiente ilustración que muestra las identidades de implementación, IaC y Acciones de GitHub 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 los pull requests no tienen acceso directo a estos secretos, se ofrece una manera para que los desarrolladores inicien acciones de forma segura sin tener 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 de Git es una fuente de verdad para la configuración, pero no le indica los URI específicos y la información de estado sobre lo que ha creado. Sin embargo, seguir un enfoque de todo como código brinda una fuente de información que se puede utilizar para sintetizar un inventario de la infraestructura provisionada. Su proveedor también puede ser una buena fuente de esta información a 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 llevó al auge del concepto de policy as code. 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 de 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.

Utilice todo como código para sus propios escenarios

El concepto de "Todo como código" amplía estos patrones a una amplia variedad de tareas de automatización y configuración más allá de la Infraestructura como Código (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 PR se convierte en una buena experiencia de usuario autoservicio base para varios procesos, especialmente cuando estás comenzando. Los procesos obtienen naturalmente las ventajas de seguridad, auditoría y reversión que proporciona 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 las mesas de servicio son un riesgo potencial de seguridad porque es posible exceder la provisión de acceso. Al usar los equipos como patrón de código, la combinación de Git y PR 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 la entrada de blog describe los derechos de todos los empleados, puede aplicar el concepto de equipos como código a escenarios más específicos de equipos de desarrollo. 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 configuró para usar el proveedor de identidades (por ejemplo, Microsoft Entra ID) para el inicio de sesión único (SSO).
• Use 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 de 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 en el equipo también se pueden almacenar en este mismo lugar (por ejemplo, a través de CODEOWNERS). La referencia a un usuario en estos archivos es el proveedor de identidad, pero este repositorio actúa como fuente única 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 la confirmación de Git para la auditabilidad.
• Los responsables y usuarios pueden crear solicitudes de extracción para añadir o eliminar personas, y los responsables de desarrollo y otros roles pueden crear nuevos equipos mediante solicitudes de extracción usando un archivo de equipo nuevo a partir de una plantilla.
• Cada vez que se fusiona un pull request en main, un sistema de CI/CD vinculado al repositorio actualiza el sistema del proveedor de identidades y todos los sistemas dependientes según corresponda.

En concreto, el sistema CI/CD:

• Usa la API adecuada del sistema del proveedor de identidades para crear o actualizar un grupo de proveedor de identidades por rol con exactamente las personas del archivo (ni más, ni menos).
• Usa las APIs de cada sistema downstream para vincular el concepto de agrupación de sistemas a grupos de proveedores de identidad para cada rol (por ejemplo, GitHub y Azure DevOps). Esto podría dar lugar a una relación de uno a varios entre su equipo y el sistema descendente para representar un rol.
• (Opcionalmente) Usa las APIs para cada sistema de destino para implementar la lógica de permisos enlazada al mecanismo de agrupación del sistema.
• Usa una API para actualizar un almacén de datos restringido con los resultados (incluida la asociación de los identificadores de equipo del sistema descendente) que pueden ser utilizados 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 parecido a la administración de derechos de Entra, 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 descendente se mantienen en el sistema de CI/CD (por ejemplo, en GitHub Actions o Azure Pipelines) o en un servicio similar 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. Dado que es probable que los desarrolladores y los roles de operaciones relacionados ya estén familiarizados con estas experiencias de usuario, los desencadenadores manuales pueden complementar el patrón de todo como código para habilitar la automatización de actividades (o trabajos) que no tienen una representación de archivo natural o que deben automatizarse sin necesidad de un proceso de PR completamente.

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 las Acciones de GitHub, la clave para hacer esto funcionar es la API REST de Acciones para iniciar un evento de despacho y activar una ejecución de un 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, auditabilidad y visibilidad que el patrón de "todo como código". Sin embargo, algo que se debe considerar es que las acciones realizadas por estos flujos de trabajo o tuberías parecen una identidad del sistema (por ejemplo, una entidad de servicio o una identidad administrada en Microsoft Entra ID) para los sistemas de destino.

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 trasladas a los desarrolladores entre crews de características y proyectos con bastante frecuencia (por ejemplo, en organizaciones matriciales), necesitas incorporar más contratistas o estás en un equipo que se encuentra 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 líderes de desarrollo, las revisiones de código pueden ralentizar el desarrollo, dado que pueden requerir un cambio de configuración para probar y revertirlo 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 caminos pavimentados bien definidos. 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 orientación a 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.

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.

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

Lo genial del patrón de todo como código es que puede mantener a los desarrolladores en los caminos predefinidos que has 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 líderes de desarrollo pueden usar estas herramientas de línea de comandos u otras experiencias de usuario integradas para estructurar 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, 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 en el camino correcto y hacerlo correctamente

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 y 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 en buen estado, lo que le permite evolucionar o ampliar sus mejores prácticas a lo largo del tiempo.

Contenido de la plantilla

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

Contenido relacionado

• Centro de recursos de DevOps de Microsoft
• Marco de cadena de suministro seguro de contenedores
• Arquitectura de línea base de CI/CD con Azure Pipelines
• Refinar la plataforma de aplicaciones