Cuatro mejores prácticas para implementar DevOps para SAP Cloud Platform

Ya sea que la implementación de DevOps sea solo en la plataforma SAP Cloud Platform o si es un enfoque híbrido con la plataforma como una parte, es importante saber cómo los aspectos únicos de la plataforma SAP Cloud Platform forman parte de una estrategia DevOps.

DevOps tiene como objetivo hacer que el proceso de desarrollo sea más ágil y eficiente, al tiempo que reduce los riesgos asociados con el cambio. Es un conjunto de procesos, tecnologías y prácticas operativas y de desarrollo que se han adoptado en diversos grados en gran parte de la industria de la tecnología. Hoy en día, muchos equipos de desarrollo de SAP están comenzando el camino de DevOps, y los equipos que trabajan en SAP Cloud Platform no son una excepción.

Una implementación de DevOps debe adaptarse a las plataformas operativas y de desarrollo que utilizan los administradores. Aquí hay cuatro consejos para implementar DevOps para SAP Cloud Platform.

1. Salga a la cadena de herramientas DevOps compartida cuando sea posible

Utilice un repositorio Git estándar de empresa si lo tiene, en lugar del soporte del repositorio Git de SAP Cloud Platform. El mismo consejo se aplica a las herramientas de integración continua, como Drone y Jenkins; las herramientas de administración ágiles, como Jira y Azure DevOps; y las herramientas de monitoreo.

Para los equipos que no están familiarizados con las herramientas utilizadas en el resto de la empresa o para las empresas que no han adoptado este tipo de cadena de herramientas DevOps, es tentador usar solo las herramientas de SAP Cloud Platform. Pero hacerlo puede tener costos a largo plazo en términos de bloqueo innecesario y características limitadas. Por ejemplo, la infraestructura de repositorio de Git que ofrece SAP Cloud Platform carece de la mayoría de las características de GitHub Enterprise, Bitbucket, GitLab y Azure DevOps, y también puede ser innecesariamente complejo acceder desde fuera del entorno de SAP Cloud Platform.

2. Vuélvase agnóstico sobre las herramientas de desarrollo

Cuando un carpintero va a un trabajo, trae sus propias herramientas. Entonces, ¿por qué requerimos que los desarrolladores calificados usen herramientas estándar de la empresa para hacer el trabajo? El uso obligatorio de herramientas de desarrollo empresarial tiene costos reales en términos de tiempo de aceleración y accesibilidad, pero son costos que los profesionales de TI han estado pagando sin dudas durante mucho tiempo en el mundo de SAP.

Algunas herramientas de DevOps deben compartirse. El control de versiones, los sistemas de tickets y los sistemas de construcción vienen a la mente. Sin embargo, esas herramientas deben tener interfaces estándar que permitan a los desarrolladores conectarse utilizando sus herramientas de elección. WebIDE debería ser el predeterminado, pero no requiera que sus desarrolladores lo usen. Haga el trabajo para implementar la infraestructura en torno a SAP Cloud Platform para permitir la libertad de los desarrolladores. La buena noticia es que si ya ha comenzado a compartir la cadena de herramientas DevOps como se sugirió anteriormente, entonces ya casi está allí.

3. Use subcuentas para escenarios escalonados

Una cosa con la que luchan muchos clientes es cuál de las muchas abstracciones disponibles usar en paisajes escalonados. ¿Deben los entornos de desarrollo, control de calidad y producción ser aplicaciones diferentes, espacios HANA diferentes o subcuentas diferentes? La respuesta es que debe usar subcuentas separadas para diferentes paisajes ambientales. Esto puede resultar en una sorprendente cantidad de duplicación de infraestructura, porque si está utilizando la base de datos de HANA, es posible que deba ejecutar tres instancias de HANA separadas para un escenario de tres niveles.

Para ayudar a reducir esta duplicación, piense si puede usar su infraestructura DevOps para eliminar un nivel. Por ejemplo, si está utilizando el Modelo de programación de aplicaciones en la nube (CAPM), ¿realmente necesita un nivel de desarrollo? ¿O pueden los desarrolladores hacer desarrollo local utilizando los módulos CAPM Node.js y una base de datos SQLite local?

4. Use las herramientas propietarias de SAP cuando corresponda

SAP tiene muchas herramientas patentadas disponibles en SAP Cloud Platform que pueden proporcionar mucho valor. ¿Debería usarlas o quedarse con una infraestructura compartida que quizás no sea tan adecuada para el trabajo en cuestión? La respuesta, a menudo, es ambas. Quizás SAP Mobile Services es justo lo que necesita para las aplicaciones sin conexión. O tal vez tenga un grupo de desarrolladores ABAP que están ansiosos por proporcionar valor en un entorno de nube, y el entorno ABAP para SAP Cloud Platform es perfecto para usted. O tal vez Cloud ALM, Translation Services, o uno de los muchos servicios de aprendizaje automático de Leonardo son justo lo que recetó el médico.

Descubra cómo integrar esos servicios en su cadena de herramientas, procesos y prácticas de desarrollo DevOps compartidos de una manera que se alineen con el resto del enfoque de su organización. A veces, esto significa envolver esos servicios en capas de abstracción para permitir el desarrollo y las pruebas locales. Otras veces, significa construir pequeñas extensiones a su cadena de herramientas DevOps para acomodar estos servicios. Y puede haber momentos mágicos en los que los servicios están bien diseñados para integrarse en sus prácticas existentes e integrarse sin trabajo adicional.

Al igual que con muchas otras cosas, el consejo más importante de todos es aprender los detalles y luego tomarse el tiempo para alejarse y considerar el panorama general, asegurando que las decisiones que tome se alineen estratégicamente para crear valor a largo plazo para su negocio.