DevOps – Continuous delivery of value

DevOps – Continuous delivery of value

As agile methodologies started to be used in software companies, the development teams have been implementing their principles, techniques and tools. This lead to build software products releases more regularly, due to short iterations and the great dynamism of the market.

At infrastructure level, cloud computing big breakthrough allowed to configure virtual machines and environments in a programmatic and secure way. However, integrating the operational and infrastructure area to the principles and techniques of agility was omitted.

This is how DevOps emerges as the combination of people with different roles, processes and tools to allow continuous deliver value to users.

DevOps follows the principles of agility, placing continuous focus on delivering value to the user. It incorporates and integrates tools to automate the release to production of a new software version, defining rules to ensure the solution quality, security and architecture.

Automation in DevOps occurs at several levels: by defining validation rules and test each commit that makes a project team member (continuous integration), by automating the process deploy to an environment of consolidated development (continuous delivery) and by automating the process deploy to the production environment (continuous deployment).

What is the solution that Microsoft delivers for DevOps?

Visual Studio Team Services (VSTS) is Microsoft’s cloud solution to manage the entire lifecycle of a project in an integrated mode. The platform enables integrating different tools, programming languages and agile methodologies. This is complemented with a user experience that quickly enables various profiles to access and manage the project information.

Thereby a project manager will manage the portfolio of projects, the business analyst will manage user stories, the development team will manage tasks and version the source code of the application, Operations will create build and deployment rules, QA will create test cases and validate automated tests by logging events and the technical leader will create coding standards and architecture validation rules.

How to approach DevOps?

Just like with agile methodologies, you must perform an incremental approach beginning to incorporate the ALM platform to allow implementing  DevOps, such as VSTS. One good way to start is by incorporating the various roles of a project to the platform. This will lead to enhanced communication among the roles of a project, reducing implementation time and improving quality metrics applications. For example, you can use Scrum for project planning, managing versions, sprints and Product Backlog Items.

Next you can continue hosting the code in the repository VSTS and may use Git or Team Foundation Version Control and subsequently you can set the Build definition.

Defining the Build

This definition is a collection of steps that will run on each commit of the development team. VSTS allows us to compile a wide variety of technologies, such as MSBuild, Xamarin, Android, Xcode, Grunt, etc. For the handling of dependencies there are tools available such as Nuget or npm. Finally a variety of tools for automating testing, as MSTest, Xamarin Test Cloud, Cloud Load Tests, etc., can be included. In case you need to run specific scripts, utility tools can be used, such as Windows PowerShell or a Shell Script using bash. Usually the last step of a build is a publish that will generate the artifacts that then will be deployed with a Release definition.

Defining the Release

Under this definition VSTS allows us to create the varied environments to which we will deploy our devices. For example we could set up a development environment which is automatically deployed with each commit, allowing a developer to test its integrated and deployed code within minutes. This environment is going to have configured a Release definition that is going to run after the end of the Build definition associated. In this definition we will specify where and how are our artifacts will be deployed. For example it could be a Web Application Deployment to Azure or to an IIS on premise.

Other environments that could be set are testing and production. These environments would be a replica of the development environment, with the difference that they display for example to another instance of our application server, either Azure, IIS on premise or another configuration of Hockey App, etc. A very handy feature of Release settings are the Approval roles. This feature allows us to configure a user list who have the ability to decide whether or not a version is installed in an environment. It is very helpful for deciding updates testing environment and especially in the production environment.



 

DevOps – Entregando valor de forma continua

A medida que las metodologías ágiles comenzaron a utilizarse en las empresas de software,  los equipos de desarrollo fueron aplicando sus principios, técnicas y herramientas. Esto llevó a generar versiones de los productos de software con mayor periodicidad debido a las iteraciones cortas y el gran dinamismo del mercado.

A nivel de infraestructura, el gran avance del cloud computing permitió configurar máquinas virtuales y ambientes de forma programática y segura. Sin embargo, faltaba integrar el área de operaciones/infraestructura a los principios y técnicas de agilidad.

Es así que surge DevOps como la unión de las personas de distintos roles, procesos y herramientas para permitir entregar valor de forma continua a los usuarios.

DevOps sigue los principios de agilidad,  poniendo foco en la entrega continua de valor al usuario. Incorpora e integra herramientas que permitan automatizar el pasaje a producción de una nueva versión del software, definiendo reglas para asegurar la calidad, seguridad y arquitectura de la solución.

La automatización en DevOps se da a varios niveles: definiendo reglas de validación y test de cada commit que haga un integrante del equipo en el proyecto (continuous integration), automatizando el  proceso de deploy a un ambiente de desarrollo consolidado (continuous delivery) y automatizando el proceso de deploy al ambiente de  producción (continous deployment).

¿Qué solución ofrece Microsoft para DevOps?

Visual Studio Team Services (VSTS) es la solución cloud de Microsoft para poder gestionar el ciclo de vida completo de un proyecto de forma integrada. La plataforma permite integrar distintas herramientas, lenguajes de programación  y metodologías ágiles. Esto complementado con una experiencia de usuario que permite rápidamente a los distintos perfiles acceder y gestionar la información del proyecto.

Es así que un project manager podrá gestionar el portafolio de proyectos, el analista de negocio podrá gestionar historias de usuario, el equipo de desarrollo podrá gestionar las tareas y versionar el código fuente de la aplicación, operacionespodrá crear las reglas de build y deployment, QA podrá crear casos de prueba y validar las pruebas automáticas registrando incidencias, y el líder técnico podrá crear reglas de validación de estándares de código y arquitectura.

¿Cómo abordar DevOps?

Al igual que con las metodologías ágiles, se debe realizar un abordaje incremental comenzando por incorporar la plataforma de ALM que me permita implementar DevOps, como ser VSTS. Una buena forma de comenzar es incorporando a los distintos roles de un proyecto a la plataforma. Esto llevará a mayor comunicación entre los roles de un proyecto, reducir los tiempos de implantación y mejorar las métricas de calidad de las aplicaciones. Por ejemplo, se podrá utilizar Scrum para realizar la planificación del proyecto, gestionando las versiones, los sprints y los Product Backlog Items.

Luego se puede continuar por alojar el código en el repositorio de VSTS, pudiendo utilizar Git o Team Foundation Version Control y a continuación se puede definir el Build definition.

Definiendo el Build

Esta definición es el conjunto de pasos que se van ejecutar en cada commit del equipo de desarrollo. VSTS nos permite compilar una variedad amplia de tecnologías, como son MSBuild, Xamarin, Android, Xcode, Grunt, etc.  Para el manejo de dependencias se ofrecen herramientas como Nuget o npm. Finalmente se pueden incluir distintas herramientas para automatización de testing, como MSTest, Xamarin Test Cloud, Cloud Load Tests, etc. En caso de necesitar ejecutar scripts específicos, se pueden utilizar herramientas utilitarias, desde un Windows PowerShell hasta un Shell Script usando bash. Típicamente el último paso de un build es un publish que va a generar los artefactos que luego vamos a desplegar con un Release definition.

Definiendo el Release

En esta definición, VSTS nos permite crear los distintos entornos a los cuales vamos a desplegar nuestros artefactos. Por ejemplo podríamos configurar un entorno de desarrollo al cual se despliega automáticamente con cada commit, permitiendo a un desarrollador probar su código integrado y desplegado en minutos. Este entorno va a tener configurado una Release definition que se va a ejecutar luego de que finalice el Build definition asociado. En esta definición vamos a especificar a donde y como se van a desplegar nuestros artefactos. Por ejemplo podría ser un Web Application Deployment a Azure o a un IIS on premise.

Otros entornos que podríamos configurar son testing y producción. Esto entornos serían una réplica del entorno de desarrollo, con la diferencia de que despliegan por ejemplo a otra instancia de nuestro servidor de aplicaciones, ya sea Azure, IIS on premise o a otro configuración de Hockey App, etc.  Una funcionalidad muy útil de la configuración de la Release son los roles de Approval. Esta funcionalidad nos permite configurar una lista de usuarios que tienen la capacidad de decidir si una versión se instala o no en un entorno. Es útil para decidir actualizaciones del entorno de testing y sobre todo del entorno de producción.

 

Share This