Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a 20150416 releasemanagement
Similar a 20150416 releasemanagement (20)
Más de Ricardo González
Más de Ricardo González (20)
20150416 releasemanagement
- 1. C# Release Management con Visual Studio y Azure Ricardo Gonzalez Vargas Microsoft Regional Director - Bogotá CEO – Androcial / WomyAds.com @rgonv - rgonzalez@androcial.com http://about.me/ricardo.gonzalez
- 3. C# Agenda • DevOps • Los retos del despliegue de aplicaciones • Tendencias del ciclo de vida de las aplicaciones • Objetivos y problemas de la gestión de liberación • El proceso de entrega • Automatización
- 4. C# Que es DevOps? DevOps es una tarea de equipo DevOps permite mejores practicas de desarrollo y entrega Inversion complete en el ciclo de vida DevOps acelera la ultima milla de la entrega continua App Lifecycle
- 5. C# Que impulsa DevOps? Los métodos agiles aceleran el proceso de construcción Las actuales “mejores practicas” de ITLM/ITSM hacen del proceso de entrega algo confiable pero no ágil Desconexión entre desarrollo y operaciones incrementa los errores y MTTR Determinar las próximas inversiones basados en aprendizaje ProductionDevelopment Collaboration BACKLOG REQUIREMENTS
- 6. C# NoOps (small web teams, start-ups) Enterprise DevOps (cross-functional organizations) WebOps (Google, Amazon, Twitter, Facebook, XBOX live, etc.) Sabores de DevOps
- 7. C# Reducir el tiempo de reaccion para satisfacer las necesidades del negocio Reducir la tasa de cambio y falloIcrementar la tasa de despliegue Reducir el tiempo promedio para deteccion y reparacion de problemas (MTTD, MTTR) Indicadores de Agilidad Indicadores de Confiabilidad Metas y métricas de éxito en DevOps
- 8. C# ProductionDevelopment Collaboration BACKLOG REQUIREMENTS Impedimentos actuales para DevOps Liberaciones inconsistentes y caoticas No tiene informacion accionable y contextual para resolver incidentes Seguimiento y gestion inconsistente a traves de equipos y herramientas Priorizacion y validacion basada en datos cuantitativos y cualitativos Resolucion y deteccion rapida de problemas en las aplicaciones
- 9. C# Retos de gestión de liberaciones (release management)
- 10. C# Tendencias del ciclo de vida de aplicaciones
- 11. C# Metas de la gestión de liberación • Generación mas rápida de valor • Software de alta calidad y baja tasa de defectos • Reducción del riesgo de despliegue • Mejoramiento continuo del proceso de liberación • Provisión de métricas y transparencia
- 12. C# Problemas de la gestión de liberación • Producir resultados consistentes en el empaquetado y despliegue • La asignación de recursos toma tiempo y es difícil de estimar • Tantas piezas adicionan riesgo, complejidad y errores
- 13. C# El proceso de Despliegue
- 14. C# Optimización del ciclo de entrega
- 17. C# Demo
- 19. C# Automatización de la liberación
- 20. C# Automates deployments Automatizando el ciclo de liberación DEV QAINT PROD TeamFoundation Server
- 21. C#Automation available to all stages Automatizando el ciclo de liberación DEV QAINT PROD TeamFoundation Server
- 22. C#Automates workflow Automatización del ciclo de liberación DEV QAINT PROD Team Foundation Server
- 23. C# DEV QAINT PROD Team Foundation Server Full traceability Automatizando el ciclo de liberación
- 24. C#TeamFoundation Server Drop Location RM ClientRM Web QA DEV RM Server Como funciona
- 25. C# Información adicional Release Management for TFS 2013 http://www.microsoft.com/visualstudio/inrelease Visual Studio 2013 http://www.visualstudio.com Team Foundation Service http://tfs.visualstudio.com/ Application Lifecycle Management http://www.microsoft.com/visualstudio/eng/alm
- 26. C#
Notas del editor
- DevOps is a relative new term, people refer to individual capabilities to automate the release pipeline as DevOps. However, DevOps is more than that is increasing the scope of agility and should be view as a team undertaking. It requires teams to look at their full lifecycle investments. At its core DevOps enables better software development and enables delivery, accelerating last mile of continuous delivery.
- What is driving DevOps? The agile methodologies are accelerating the construction process and creating a significant pressure to Operations teams to update their existing practices to make enable faster cadence, in other words changing and adopting existing process to not only be reliable but also support and agile cadence. In our internal teams and with some of our enterprise customers we noticed that once a team is able to accelerate the construction phase consistently. The next evolution process is to ensure such applications remind available and performing as expected. And when they aren’t having access to information and tools that allow both Operations and development teams to diagnostic and fix issues quickly. Then these teams become more sophisticated and mature and then they want to have access to customer usage information to use quantitative and qualitative data to help them determine the next set of investments and enable continuous learning.
- We observe three DevOps flavors: WebOps: companies and teams that have high levels of automation and deliver incremental updates and value very frequently (often hourly. xBox live or Big are good internal examples). NoOps: applies to small teams or start-up teams where there isn’t a dedicated operations team, instead the developers perform operational work. And Enterprise DevOps: where there are dedicated Operations and Development teams, driving the need for great team collaboration.
- Companies looking at implementing DevOps practices are balancing two important performance indicators. Agility: their ability to increase deployment frequency and reduce change lead time to react to dynamic business needs. And Reliability: reducing change fail rate and reduce the time to take them to detect and repair production issues. These are very hard to balance metrics and create friction across teams.
- When looking at these friction and challenging points we identify 5 top impediments for DevOps Inconsistent and chaotic releases: how to shift from quarterly or monthly release to a more frequent release cadence like daily for example. When you have multiple teams releasing daily it is hard to keep track of what is going to production and who approved it. Quickly detect and resolve application issues: as the team increases their cadence and components run in hybrid environments it becomes more difficult to diagnostic issues in production without proper tools that facilitates this for developers. Inconsistent tracking and management of incidents across teams and tools: Developers and operations use their own tools to manage their own work, while this tools serve different purpose they need to be integrated so there is consistency traceability and transparency around managing incidents, tools that enable collaboration without adding unnecessary overhead. Prioritize and validate investments based on qualitative and quantitative data: allowing teams to be in continuous learning mode. No actionable and contextual info to resolve incidents: it is often the case that production is a unique environment and reproducing issues using pre-production environments could be challenging. To remove friction and increase efficiency, developers need access to rich diagnostics and information that allow them to resolve production issues quickly. So let’s take a look at each area, and talk about problems, solutions and customer value…
- Applications, and the associated set of user expectations, have evolved significantly over the past few years. Applications are expected to run on many different platforms, data is expected to be readily available, and social tools built in. In addition, as business needs and technology continues to change rapidly, developers need to be able to quickly deliver value to customers and integrate feedback. In this session, we’re going to dig deeply into how our new wave of products better enables continuous delivery.
- When we think about the lifecycle of a specific version of an application, we often break it down into the stages it must go through to see the light of production. You’ll typically start with a development environment for a developer or small team to coordinate on. After the build passes that stage, it’ll need to be run through an integration environment where the work from the entire application unit is brought together. If that all goes well, the app will need to be deployed to a QA environment for greater testing. With success there, it’ll move on to one or more stages of production in order to be accessible to users. [Build] As a build moves down the pipeline toward production, more people get involved and the need for coordination increases significantly. You also have to account for the nature of the deployment environments, especially as load testing and other requirements may result in differences in the topography of the environment itself. You want to make sure each phase has the same build deployed in the same way. And, of course, if you invest in automation, there’s testing time to take into account for the process itself.
- If we approach the process from a developer’s perspective, the steps abstract out a little bit. First, you’ll start off by writing code in your tool of choice. You’ll run builds and package as needed before provisioning an environment, deploying the app, and testing it. At the end, the app is approved and gets pushed out to production. [Build] However, it really turns out that the application is more likely to have lots of different builds deployed and tested before one passes the quality gate and can get pushed through. In addition, a build will likely need to go through the environments we discussed earlier, resulting in a need for the repeatable deployment model. [Build] Microsoft’s ALM platform is deigned to support this approach, which makes it easier for issues that get raised during the test process to cycle back through the development cycle so that they can be addressed and pushed through the release cycle again.
- A major goal is the ability to take a single build package and push it out to each environment in the same way. [Build] This drastically reduces the amount of manual effort required to update the environments and can make the entire process much smoother.
- Another important aspect to each release environment is what we’ll refer to as the “stage stack”. This is a simple layout of the steps typically required to get a packaged app from a build location out to a prepared environment, through the necessary install and configuration, through the required tests, and finally approved for migration to the next stage. Microsoft has provided many of the tools to support this stack, although sometimes a little extra work is required to help it all work together. [Build] Lab Management is available to help provision environments. [Build] PowerShell is ideal for configuring environments. [Build] There are some useful built-in tools for deploying and installing the application itself. [Build] And lots of companies invest in their own custom tools to configure applications. [Build] Running automated tests during the release process is becoming the standard for applications of every type. [Build] Microsoft Test Manager handles the testing aspects. [Build] And now with Release Management for Team Foundation Server 2013, this entire process is only going to get better.
- One major benefit of the new Release Management Server for Team Foundation Server 2013 is that it provides all the automated deployment goodness we were discussing earlier.
- It also ensures that the deployments are pushed out the same way to all stages.
- Not only does it automate the overall workflow, but it provides the ability to automate approvals where necessary, such as early phase deployments. You can still keep manual approvals for deployments deeper in the release cycle.
- Finally, the whole process is recorded so that you can enjoy full traceability throughout the process. This is extremely valuable in scenarios where there are strict compliance requirements for legal or other reasons.
- Let’s take a look at how the new release management infrastructure fits into your development environment. [Build] First, you’ll deploy Release Management Server. [Build] Next, you’ll install deployment nodes on the target systems in your deployment environments. [Build] You can then configure Release Management Server to pull builds from TFS and push them out to the specified environment. [Build] There is also a client app and Web UI that allow users to interact with the release management, workflow, and reporting features. A release typically gets triggered by an automated event, whether it’s a check-in or on a schedule. However, you can manually create a release as well. Once a release is begun, it works its way down the “release path”, which might be “Dev to QA to Production” with automated and/or manual gates at each. The paths are composed on the various servers grouped into environments on which the testing for the stage is performed. Once an application needs to be deployed to a new environment, the server will queue deployment requests to all the required target servers for each component of the application. This allows an atomic deployment of all the components. The Release Management Deployment Agent running on each target server monitors the Release Management Server continually, at a configurable interval, and will pick the installation requests for the one or many components it needs to install locally. The Deployment Agent will then find and download the release package, provided by the Release Management Server. RMS calculates the location using the TFS API, if built by TFS, or using a predefined UNC path if not. Finally, the Deployment Agent downloads any additional executables, such as batch files, PowerShell scripts, EXEs, etc., to be run as part of the installation. These are additional deployment activities beyond the installation itself. Creating test data or triggering automated tests are common scenarios here.
- Preview URL: http://www.microsoft.com/visualstudio/inrelease/