We are continuing to cover the multi-developer story for IaaS contents as a code. In the previous blog we have shown step-by-step process on how to set up IaaS content development environment using vRealize Automation with Infrastructure blueprint that is available for download from vRA 7.4 appliances.
Here we will be focusing on implementing the main part of Multi-developer story for IaaS as code: how to enable developers to work with IaaS content similar to how “regular” software developers work with traditional source code.
Introduction: IaaS Content Development Lifecycle
Similar to Software Development Life Cycle (SDLC) where multiple developers check-out source code from SCM repository (such as Git/GitLab), modify it in their Development environments, perform unit tests, check modified source code into repository for it to be deployed to production, vRealize Suite LifeCycle Manager (vRLCM) provides functional support for conceptually similar Content Development Life Cycle (CDLC) with its internal Common repository and integration with external SCM systems and embedded vRealize CodeStream for code delivery stages (Capture, Test, Release) automation.
The architectural diagram below illustrates how vRLCM supports CDLC:
As with SDLC where there are different roles (Developer, Release/Build manager), CDLC also supports dedicated user roles (with persona code names attached for simplification):
- Cloud Administrator (“Jason”) and/or Release Manager (“Shauna”) are able to replicate content from a Central repository across various product instances or tenants
- “Jason”, “Shauna” and Content developer (“Scott”) can interact with content and its dependencies in a way that maintains a single copy of all shared/embedded content
- “Shauna” can review checked-in content changes and approve or reject them based on unit test results and other factors
The high-level flow diagram below illustrates these stages of CDLC and relevant user roles:
(“Scott” – Developer) 
(“Shauna” – Release Manager )
Configure Content Management Endpoints in vRLCM Content Management Functional Area
Before being able to work with IaaS Content in local Development environment, we need to configure Content endpoints in vRLCM. For a reference, this blog is a very good hands-on introduction to initial Content Endpoint configurations, including one for GitLab.
As a brief reminder, Content endpoints (for vRealize Orchestrator, vRealize Automation and GitLab) can be created from the Content Management – Endpoints menu.
When creating/editing Content endpoint information, the required fields: Endpoint name, server FQDN/IP and login credentials should be specified, and API connection can be tested prior to saving content endpoint:
For Content endpoints connected to Production environments we recommend selecting the following policies, as shown below:
- “Mark as Production Content Endpoint” policy restricts content deployment to user(s) with Release Manager role only. Also content must be marked as “Production Ready” to be deployed to that endpoint.
- “Source Control Enabled” policy enforces restriction on content that can be deployed to this environment, specifically marked as “source control” (see details below). That policy setting is recommended for multi-developer environments where various team members are checking content into centralized SCM system.
For Content endpoints connected to Development environments, “Mark as Production Content Endpoint” policy is typically not selected so any developer can deploy content to it and content does not have to be marked as “Production Ready”. Depending on plans on how to populate initial content into Development environment – capture directly from Production environment, from previously captured content already in the LCM repository or from content captured via SCM (marked as “source control”) – the “Source Control Enabled” policy should be selected or deselected.
Policy selections however can be changed for both vRA and related vRO Content endpoints at any time by editing its settings and submitting with summary of changes displayed before submission:
Changes to content endpoint policies will become effective immediately.
Populate Development Environment with Production content from LCM content repository
Next important step in CDLC implementation is checking out content into Development environment. That can be done number of ways, depending on policies applied to content endpoint.
We will illustrate scenario when Developer checks out content (Composite Blueprint) that was previously captured into LCM repository but not marked “Production Ready” and not checked-in/captured from SCM repository, which is pretty common for environments starting to centralize their CDLC.
Note that this composite Blueprint was previously captured with its dependencies included (property groups, software components etc.) so these dependencies will be deployed into Development vRA environment as well.
Once Deploy button is clicked, user is presented with “Deploy” dialog where destination environment(s) that allow deployment of that content according to their policies can be selected and comments entered:
Note that we have selected all 3 checkboxes to make sure that we are capturing and releasing latest content dependencies and should unit testing process experience a failure – deployment process will stop and content will not get deployed to a target environment.
As with any CDLC request in LCM, for its run time monitoring we navigate to the “Content Pipelines” area showing executions of embedded vRealize Code Stream Content pipelines invoked by our request and can review its details and status in UI formatted or “raw” JSON format:
Note that default Unit tests are executed during “Test Content” stage of Content Pipeline. Developers may also implement their own custom logic for testing/validation of content they are working on, including test deployment into target environments using vRO workflows etc. Also, if “Source Control enabled” policy was enabled on our Development content endpoint – we could deploy content previously captured from SCM repository by Release Manager.
As a result of this request, our vRA Development environment gets selected blueprint and all its dependencies deployed and ready for further development work:
(Other blueprints shown on the screenshot have been deployed into this environment by prior LCM requests or manually).
Modify Content in Development Environment
Now we as Developers are ready to work on the deployed IaaS content: modify it, add new dependencies if needed and integrate with other content (such as vRO workflows) that can be captured separately.
For simplicity, we will focus on modifications to Blueprint itself in vRA. As shown on the screenshots below, we will modify Blueprint description with note about time of last change,
expand VM max storage capacity to 500 GB
and add a new Custom property with a value that can be used in a provisioning process:
In real life situations, Developers can make more complex changes to Blueprint and/or its dependencies (Software components, Property groups, Event Broker subscriptions etc.) – all these changes can be handled by LCM Content Management very similarly to shown in the following sections
Capture Modified Content into LCM Repository With Unit Testing
Now that we have modified IaaS content in our vRA Development environment and saved changes, we are ready to “commit” them to LCM centralized content repository so the new content version will be available.
We start in the ‘Content’ area, select name of the blueprint from the content inventory list and click “Capture” button in the upper right corner of the screen. That will bring up the Capture request form:
We select Content endpoint corresponding to the Development environment where we performed the change, enter tags that reflect nature of operation and type of environment, mark this version (to be created) as “Production ready” (since it is our intent to have it published to Production environment), enter comments and click “Capture” button.
As for all LCM Content management requests, we can monitor progress of capture via “Content Pipelines” view:
Note that a new content version (4) has been created in the LCM Content repository upon successful completion of the request above. We can verify that by reviewing the Version list for the “vRA Patch management Dev Environment” blueprint that displays the new version number and “Production Ready” tag.
Now we are ready to check in our modified IaaS code into SCM repository!
Check-in Modified Content into SCM and Capture it from SCM for Production Deployment
We need to Check in the captured version into SCM system since our Production environment only allows deployment content captured from SCM (b/c “Source Control Enabled” policy is enforced on the Production content endpoint).
We specify SCM “VMW GitLab” as target endpoint (that choice will populate Repository and Branch values with those configured for that endpoint) and check “Include all dependencies” box to make sure that all dependent content elements are checked in as well, then click “Check In” button:
Upon completion of that request, users with Release Manager responsibilities (who have merge entitlements for target GitLab repository) will see pending Merge requests in the GItLab UI:
Upon entering merge comments and approving merge requests, they will appear in the GitLab Commits view:
Now that the modified IaaS content is checked into SCM repository and these changes are merged, either Developer or Release Manager need to capture it from there and mark it “Production Ready” so it can be deployed into Production environment:
Upon completion of Content pipeline execution, a new version (5) appears in the “Versions” tab tagged as “Production Ready” and “Source Controlled” with SHA hex value displayed that corresponds to GitLab Commit request SHA code:
Now that the checked-in IaaS code from the SCM repository is captured into LCM – it is ready for Production deployment
Production Deployment of Checked in Content by Release Manager
Finally, after modified IaaS content is checked into SCM repository, merged into “master” code branch and captured from there in that state into LCM content repository, we are ready to deploy it into Production.
Release Manager user (“Shauna” in the flow diagram at the beginning) logs into LCM, selects the latest version of the content tagged as “Production Ready” and “Source Controlled” and clicks the “Deploy” button which brings up a dialog like one show below:
Production content endpoint is selected and checkboxes for inclusion of dependencies and stopping release on a first unit testing failure are checked, then “Proceed” button is clicked. As with previous LCM requests, a new Content pipeline is executed that carries out that request:
Upon its successful completion, Release Manager can verify that the new version of Blueprint “vRA Patch Management Dev Environment” with its dependencies is deployed into Production vRA environment:
machine resource storage limit is increased to 500 Gb and the new custom property “newproperty” is present as well:
Similar CDLC processes can be used for checking out, modifications, check-in and release to Production for other types of vRA and vRO content types.
Summary
With vRealize Automation Infrastructure blueprint and vRealize Suite Lifecycle Manager Content Management functionality available, IaaS content developers are now able to:
- Rapidly provision IaaS content Development environments from vRealize Automation Production environment.
- Configure Content management endpoints in vRealize Lifecycle Manager Content management functional area
- Populate Development environments with replica of Production IaaS content for development.
- Capture/Recapture modified/added content into central LCM content repository with unit testing.
- Integrate with SCM to enable multi-developer scenario by allowing content check-in and check-out.
- Review changes and deploy checked in and validated content from SCM to Production environment by DevOps Release manager.
Please leave your feedback and questions in the Comments section below and let us know about your journey on the path to IaaS as code lifecycle automation!
