To really understand how DevOps can be useful to the virtualisation administrator, we have to take a look at what DevOps is, what problems it tries to solve, and how it solves them. Wikipedia describes DevOps as:
a set of practices that combines software development (Dev) and information-technology operations (Ops) which aims to shorten the systems development life cycle and provide continuous delivery with high software quality
Although the finer points of DevOps can be subjective, most definitions agree that broadly DevOps should have the following benefits:
- Minimise the time to deliver value – that is, to deliver a request in the shortest amount of time possible
- Faster release cycles – smaller, more frequent release cycles
- Continuous, iterative improvements
- Reduced failures and rollbacks
- Faster resolution and earlier detection of problems
The DevOps Cycle
The DevOps cycle is a continuous loop, broken down into various stages. There are differing definitions of the stages, but the majority seem to converge on
- Plan
- Gather requirements to define a product roadmap consisting of epics, features, user stories.
- Create a backlog of tasks that reflect the gathered requirements.
- Define sprints to plan which work should be completed in a set time period.
- Code
- The developers begin writing the code to deliver the tasks that are part of the sprint.
- Manage the code using a version control system like Git.
- Build
- Commit code to a shared repository and merged with the existing codebase.
- There may be a lightweight peer review at this point to catch obvious errors.
- Trigger an automated process to build the new codebase and run a series of tests, typically unit tests, integration tests and smoke tests.
- Test
- Deploy a staging environment using infrastructure as code to ensure a consistent test environment.
- Execute automated and manual testing, such as security and vulnerability scanning, and user acceptance testing.
- Release
- There’s now a high level of confidence in the code and it can be released to production.
- Depending on the maturity of the organisation in DevOps terms, a pipeline may release new builds to production automatically. Alternatively, you can use feature flags, scheduled releases, or manual approval processes.
- Deploy
- Released builds are now ready to deploy to the production environment, which should also be managed using the same infrastructure as code as the staging environment to assure the released build will be successful.
- Using a green/blue deployment strategy to deploy in parallel with the existing production environment, and seamlessly switch to the new codebase. Switch users back to the previous environment in the event that the release introduces an issue and until a fix is released.
- Operate
- Now that the code is live, capture information from the operations team, the hosting provider and the users.
- Users should have a mechanism to provide feedback from within the platform.
- The operations team, or the hosting provider, may configure auto-scaling based on the application load.
- Monitor
- Capture performance metrics, logging data and errors.
- Feed this data, and the data captured during the operate phase back into the next planning phase.
- You can also capture any inefficiencies in the pipeline itself at this stage.
The loop begins again, with the plan stage feeding from the operate and monitor stage to initiate the next cycle. In reality there should be no start or end to the loop – it’s one long continuous process of integration, delivery, deployment and feedback.
The DevOps Cycle in vRealize Automation
If we translate the DevOps cycle into the vRealize Automation world, the development of a new application blueprint might look something like below.
- Plan
- Capture the application requirements and define what it is that the blueprint should be doing.
- Code
- Write the YAML code – whether that’s in the Cloud Assembly Blueprint Designer interface, or using an IDE like Visual Studio Code.
- Commit the YAML blueprint to source control (e.g. GitHub or GitLab).
- Build
- Merge the new blueprint code with the Development branch in source control and synchronise with Cloud Assembly.
- A development environment is defined using infrastructure as code and deployed as part of the build.
- Deploy the blueprint into the development environment and trigger a Code Stream pipeline to run unit tests, integration tests or smoke tests.
- Test
- Merge the Development branch into the Staging branch.
- A source control webhook triggers a Code Stream pipeline to begin testing, for example a security and vulnerability scan or automated application tests.
- Release
- Publish a new version of the blueprint to the production catalog. This can be automated based on the test pipeline and configures a new custom form in Service Broker.
- Deploy
- End users deploy the new blueprint into the production environment, or upgrade an existing deployment using a blue/green methodology.
- Operate
- Users operating the new blueprint can provide feedback on the latest iteration.
- Operations teams fine tune the deployment, for example, vRealize Operations might report the need for additional memory or processing power. The Service Broker, Cloud Assembly or API interfaces can scale the application deployment.
- Monitor
- vRealize Operations and vRealize Network Insight monitor the application and networking, and vRealize Log Insight collects log data.
- Network Insight might identify a new firewall rule requirement, which is fed back into the planning team to incorporate into the next iteration of the blueprint.
Mapping DevOps Concepts to vRealize Automation
The diagram below shows the DevOps cycle stretched out, with the concepts mapped to stages. vRealize Automation employs Infrastructure as Code (IaC) to provide consistent, cloud-agnostic environments into which new blueprint is deployed – this maps to both the Test and Deploy phases.
- Continuous Integration – YAML code written in the Code phase is merged with the central code base and automatically built in the development environment.
- Continuous Delivery – Extends the Continuous Integration concept to deploy and validate the blueprint in the staging environment, ensuring that it’s ready to release to production.
- Continuous Deployment – Takes Continuous Delivery one step further and automatically releases a blueprint that has passed the automated testing into the production environment.
- Continuous Feedback – Data gathered from operating and monitoring the deployed blueprint provide feedback into the design process.
- Iterative Development – As the development of the blueprint moves around multiple cycles, incremental improvements are made and new versions released.
Next steps
This blog post is a summary of a webinar “Infrastructure DevOps – Part 1: From VI Admin to DevOps Champion with vRA” delivered by my colleague Lefteris and myself, and which you can now view on-demand. It forms the first part and the groundwork for a further series of webinars (and subsequent blog posts):
- Part 2: Infrastructure as Code – April 2020
- Part 3: Iterative Development – May 2020
- Part 4: Infrastructure Pipelines – June 2020
Keep your eyes on the Events and Webinars pages for the details or sign up for vRA Cloud Communications to receive notifications when the next webinars are scheduled.
