De qué forma acelera GitHub la adopción de la nube

Información general

La innovación es la nueva moneda del actual paisaje de la competitividad. El uso compartido del vehículo, el contenido del streaming, los automóviles autónomos y otros servicios han cambiado radicalmente el ritmo de vida diario de las personas, han dado un giro de 180 grados a los mercados y han mostrado a las claras que el panorama de la competitividad ha pasado de los recursos físicos a experiencias digitales.

Estos tipos de experiencia digital superior están provocando una brecha, ya que las empresas consolidadas se enfrentan a la feroz competencia de las empresas que pueden innovar y proporcionar valor a sus clientes más rápidamente. Para competir y evitar dicha brecha, las empresas necesitan crear una cultura de innovación y usar las herramientas y los servicios en la nube mejores y más apropiados.

GitHub proporciona una variedad de características que pueden ayudar a las empresas a:

  • Sacar provecho de las funcionalidades y los servicios de Azure.
  • Modernizar sus prácticas.
  • Ser más ágiles e innovadoras durante este cambio de cultura.

Las empresas pueden aprovechar las ventajas de la conectividad de GitHub con la comunidad de código abierto y encontrar miles de ejemplos de soluciones en la nube reiterados, mejorados y listos para implementar de organizaciones que han adoptado correctamente los servicios de Azure. Pueden tomar prestadas fácilmente estas soluciones y seguir usando estas soluciones para adaptarlas a sus necesidades empresariales.

GitHub facilita que las organizaciones pongan en práctica la cultura del uso compartido dentro de sus equipos, lo que agiliza la modernización e implementación de aplicaciones o cargas de trabajo. Las empresas pueden girar sus ojos hacia la metodología InnerSource, que es un principio clave de la innovación, para tomar prestados de la comunidad de código abierto procedimientos recomendados como el uso compartido y la reutilización, la colaboración y comunicación, entre otros, y aplicarlos en su organización.

Desde la protección de los paquetes de código abierto hasta la propiedad intelectual que se escribe diariamente, la protección de toda la cadena de suministro de software debe ser una prioridad principal para todas las empresas. Este objetivo requiere una tecnología de seguridad avanzada que se puede incorporar y automatizar durante todo el ciclo de vida, y varias funcionalidades nativas de GitHub, como GitHub Advanced Security y Acciones de GitHub, ofrecen este tipo de flexibilidad.

Aprovechamiento de los recursos de código abierto

Las organizaciones muy eficaces reconocen el software de código abierto (OSS) como esencial, no opcional, para el desarrollo de software moderno. Participan en las comunidades de desarrolladores de las que dependen y usan una plataforma segura para invertir estratégicamente en software de código abierto. El resultado de estas acciones es que estas organizaciones disfrutan de las innovaciones rápidamente, superan a sus competidores y reducir los costos, al mismo tiempo que minimizan los riesgos.

Aunque el software de código abierto podría interpretarse como los paquetes, bibliotecas, scripts y dependencias que se incorporan en las aplicaciones, hay miles de recursos de código abierto, que adoptan la forma de infraestructura como código (IaC), documentación, guía y planos técnicos para arquitecturas de Azure bien definidas. Los asociados, proveedores y usuarios de Microsoft han contribuido con estos planos técnicos a la comunidad de software de código abierto y están disponibles en GitHub. Además, resultan fáciles de modificar, reutilizar e implementar en un entorno específico de Azure.

Infraestructura como código

Infraestructura como código (IaC) es la administración de la infraestructura (redes, máquinas virtuales, equilibradores de carga y topología de conexión) en un modelo descriptivo y usa el mismo sistema de control de versiones que utiliza el equipo de DevOps para el código fuente. Al igual que el principio de que el mismo código fuente genera el mismo archivo binario, los modelos de IaC genera el mismo entorno cada vez que se aplica. IaC es una práctica clave de DevOps que se usa con la entrega continua (CD).

IaC ha evolucionado para resolver el problema de desfase del entorno en la canalización de versión. Sin él, los equipos deben mantener la configuración de los entornos de implementación individuales, y las incoherencias entre los entornos generan problemas durante las implementaciones. En último término, cada entorno se convierte en un copo de nieve, una configuración única que no se puede reproducir automáticamente. Con los copos de nieve, la administración y el mantenimiento de la infraestructura implican procesos manuales que facilitan la aparición de errores y cuyo seguimiento es difícil de realizar. Las implementaciones de infraestructuras con IaC se pueden repetir y evitan los problemas en tiempo de ejecución que provocan el desfase en la configuración o las dependencias que faltan.

Con IaC, los equipos realizan cambios tanto en la descripción del entorno como en el modelo de configuración, que habitualmente está en formatos de código bien documentados como JSON; para más información, consulte las plantillas de Azure Resource Manager. Para simplificar sus flujos de trabajo, los desarrolladores pueden hospedar el código IaC en el mismo repositorio de GitHub en el que se encuentra el código fuente de su aplicación y adoptar las mismas prácticas de CI/CD de integración para IaC con la tecnología de Acciones de GitHub.

En la acción de GitHub AzOps encontrará un ejemplo de cómo implementar plantillas de Resource Manager personalizadas en varios ámbitos de Azure. Si es la primera vez que usa las plantillas de Resource Manager o IaC, también puede examinar el azure-quickstart-templates repositorio en GitHub, buscar la plantilla que desea implementar y seleccionar el botón Implementar en Azure para probar el funcionamiento.

Screenshot of a Deploy to Azure button.

Componentes y procedimientos recomendados del patrón en la nube

El siguiente diagrama de arquitectura resalta las comprobaciones de seguridad que se ejecutan en los componentes de GitHub y Azure en un entorno DevSecOps de GitHub:

An architecture diagram highlighting the security checks that run in the GitHub and Azure components of a GitHub DevSecOps environment.

  • GitHub proporciona una plataforma de hospedaje de código que los desarrolladores pueden usar para colaborar en proyectos tanto de código abierto como de InnerSource.

  • Codespaces es un entorno de desarrollo en línea. Esta herramienta está hospedada en GitHub y tiene la tecnología de Visual Studio Code, y proporciona una solución de desarrollo completa en la nube.

  • La seguridad de GitHub sirve para eliminar amenazas de varias maneras. Los agentes y servicios identifican las vulnerabilidades de los repositorios y los paquetes dependientes. También actualizan las dependencias a las versiones seguras actualizadas.

  • Las Acciones de GitHub son flujos de trabajo personalizados que proporcionan las funcionalidades de CI/CD directamente en los repositorios. Los equipos denominados ejecutores hospedan estos trabajos de CI/CD.

  • Microsoft Entra ID es un servicio multiinquilino de identidad basado en la nube que controla el acceso a Azure y a otras aplicaciones en la nube, como Microsoft 365 y GitHub.

  • Azure App Service proporciona un marco para compilar, implementar y escalar aplicaciones web. Esta plataforma ofrece mantenimiento de infraestructura integrado, revisiones de seguridad y escalado.

  • Azure Policy le ayuda a administrar y evitar problemas de TI mediante definiciones de directivas que pueden aplicar reglas a los recursos en la red. Por ejemplo, si un proyecto está a punto de implementar una máquina virtual con una SKU no reconocida, Azure Policy envía alertas del problema y detiene la implementación.

  • Microsoft Defender for Cloud proporciona características unificadas de administración para la seguridad y protección contra amenazas en todas las cargas de trabajo en la nube híbrida.

  • Azure Monitor recopila y analiza métricas de rendimiento, registros de actividad y otros datos de telemetría de la aplicación. Si este servicio identifica condiciones irregulares, alerta a las aplicaciones y al personal.

Metodología InnerSource

Introducción a la metodología InnerSource

Muchas empresas usan el término metodología InnerSource para describir la forma en que sus equipos de ingeniería trabajan juntos en el código. InnerSource es una metodología de desarrollo en la que los ingenieros crean software propietario con procedimientos recomendados de proyectos de código abierto a gran escala, como Kubernetes o Visual Studio Code.

Los proyectos de código abierto a gran escala requieren coordinación y trabajo en equipo entre miles de colaboradores. Los que más éxito cosechan son los movidos por una visión tanto de su futuro como de las necesidades diarias de los usuario: velocidad, confiabilidad y funcionalidad. La escala en que funcionan estos proyectos pueden servir de enseñanza y puede ayudar a las empresas a crear mejor software más rápidamente con InnerSource.

Con las solicitudes de incorporación de cambios y los problemas de GitHub, la colaboración y la revisión de código se integran en el proceso de desarrollo. Los equipos internos y externos pueden compartir su trabajo, debatir los cambios y obtener comentarios, y todo ello en un solo lugar, lo que ayuda a las organizaciones a compartir la experiencia internamente y evitar tener que reinventar soluciones probadas en el campo desarrolladas para otros proyectos.

Anatomía de un proyecto de InnerSource

La combinación correcta de personas, equipos y recursos puede garantizar el éxito de un proyecto. Muchos proyectos de código abierto siguen una estructura organizativa similar que puede ayudar a las organizaciones a configurar equipos interfuncionales para administrar proyectos de InnerSource. Los proyectos de código abierto más frecuentes tiene los siguientes tipos de personas:

  • Mantenedores: colaboradores que son responsables de impulsar la visión y de administrar los aspectos de organizativos del proyecto. Es posible que no sean los propietarios o creadores originales del código.

  • Colaboradores: todos los que han contribuido en algo al proyecto.

  • Miembros de la comunidad: las personas que usan el proyecto. Pueden estar activas en conversaciones o expresar su opinión en la dirección del proyecto.

Los proyectos más grandes también pueden tener subcomités o grupos de trabajo centrados en tareas diferentes, como la creación de herramientas, la evaluación de prioridades y la moderación de la comunidad. Es probable que los proyectos InnerSource sigan una estructura similar. Muchas organizaciones de ingeniería organizan a los desarrolladores en equipos, como ingeniería de aplicaciones, ingeniería de plataformas y desarrollo web. En las organizaciones, este tipo de estructuración puede excluir a personas calificadas. La organización de un grupo de toma de decisiones principal que tenga el apoyo de los equipos de toda la organización puede ayudar a obtener rápidamente la experiencia necesaria para solucionar los problemas con mayor rapidez.

En las empresas, los colaboradores son sus desarrolladores y los mantenedores son los jefes de proyecto y los responsables de la toma de decisiones clave.

  • Mantenedores: los desarrolladores, jefes de producto y otros responsables de la toma de decisiones clave en la empresa cuya misión es impulsar la visión de los proyectos y administrar las contribuciones cotidianas.

  • Colaboradores: los desarrolladores, científicos de datos, administradores de producto, vendedores y otros roles de la empresa que ayudan a impulsar el software. Es posible que los colaboradores no formen parte del equipo directo del proyecto, sino que ayuden a compilar el software, mediante la creación de código, el envío de correcciones de errores, etc.

Para más información, consulte las notas del producto Una introducción a InnerSource.

Automatización

Acciones de GitHub permite a los usuarios crear flujos de trabajo personalizados directamente en sus repositorios de GitHub. Los usuarios pueden detectar, crear y compartir acciones para realizar cualquier trabajo, entre los que se incluyen CI/CD, así como combinar acciones en un flujo de trabajo completamente personalizado. También pueden crear flujos de trabajo de CI que compilan y prueban proyectos escritos en diferentes lenguajes de programación. En las guías de Acciones de GitHub, encontrá varios ejemplos.

Las Acciones de GitHub se pueden usar para combinar conceptos de IaC y prácticas de CI/CD, con el fin de automatizar todo el ciclo de vida de la implementación de un extremo a otro, incluidos el aprovisionamiento o la actualización del entorno de destino de forma repetible y el empaquetado e implementación de la propia aplicación.

Ejemplo:

Las Acciones de GitHub para Azure se compilan para simplificar la forma de automatizar los procesos de implementación en los servicios de Azure de destino, como Azure App Service, Azure Kubernetes Service, Azure Functions, etc. El repositorio de flujos de trabajo de acciones para comenzar a trabajar con Azure incluye flujos de trabajo de un extremo a otro para crear e implementar aplicaciones web de cualquier lenguaje y ecosistema en Azure. Para ver todas las acciones disponibles, visite GitHub Marketplace.

Seguridad

Características de seguridad del desplazamiento a la izquierda de GitHub

Desde los primeros pasos de desarrollo, DevSecOps se adhiere a los procedimientos de seguridad recomendados. Mediante el uso de una estrategia de desplazamiento a la izquierda, DevSecOps redirige el foco de seguridad. En lugar de apuntar a la auditoría, al final, se desplaza al principio del desarrollo. Además de generar un código sólido, este enfoque de respuesta rápida a errores ayuda a resolver los problemas al principio, cuando son fáciles de corregir.

GitHub dispone de muchas funcionalidades de seguridad y ofrece herramientas que admiten todas las partes de un flujo de trabajo de DevSecOps:

  • IDE basados en explorador con extensiones de seguridad integradas.
  • Agentes que supervisan continuamente los avisos de seguridad y reemplazan las dependencias vulnerables y desactualizadas.
  • Funcionalidades de búsqueda que buscan vulnerabilidades en el código fuente.
  • Flujos de trabajo basados en acciones que automatizan todos los pasos de desarrollo, prueba e implementación.
  • Espacios que proporcionan una manera de analizar y resolver amenazas de seguridad de forma privada, así como de publicar la información.
  • Junto con la capacidad de supervisión y evaluación de Azure, estas características proporcionan un servicio excelente para crear soluciones seguras en la nube.

Ejemplo:

Las instalaciones de DevSecOps de GitHub cubren muchos escenarios de seguridad. Entre las posibilidades se incluyen los siguientes casos:

  • Desarrolladores que desean aprovechar las ventajas de los entornos preconfigurados que ofrecen funcionalidades de seguridad.
  • Administradores que confían en tener informes de seguridad actualizados y con prioridad a su alcance, junto con los detalles sobre el código afectado y las correcciones sugeridas.
  • Organizaciones optimizadas que necesitan sistemas para adquirir automáticamente dispositivos de seguridad nuevos y que no corran peligro, cuando los secretos quedan expuestos en el código.
  • Equipos de desarrollo que pueden beneficiarse de las actualizaciones automáticas, cuando las versiones más recientes o más seguras de los paquetes externos estén disponibles.

Para más información, consulte:

Pasos siguientes

  • Elija el equipo de implementación (normalmente, un administrador de desarrolladores y algunos desarrolladores definidos como administradores) e implemente GitHub.
  • Obtenga información sobre los flujos de trabajo de Git comunes y avanzados para mejorar su forma de usar GitHub.

Los siguientes vínculos proporcionan más información acerca de GitHub.