Tanzu Application Service
Tanzu Application Service (TAS) is VMware's Cloud Foundry implementation that enables developers to deploy their applications without worrying about installing dependencies or maintaining them. The developers code their applications and let the platform handle the rest.
TAS provides companies an escape from large IT infrastructure teams and software and enables smaller platform teams to handle an exponentially large workloads. Developers, on the other hand, worry about their application and what it needs and use the platform to manage and connect its dependencies.
TAS is used by governments, banks, major wireless carriers, and other critical industries where uptime and redundancy is crucial.
TAS is available as a roughly 10 GB download and uses Tanzu Operations Manager (powered by BOSH) to deploy and set up the runtime, logging, and other components necessary to deliver a feature rich platform for enterprise use.
This case study goes over how each build comes into existence, goes through rigorous testing and out to customers. The customers depend on the robust release engineering system as much as the platform and its components to deliver a system they are confident in rolling out to production.
A regular release train consists of all supported versions across all product variants. We have TAS, Small Footprint TAS, Isolation Segment (to further scale runtime capabilities), and Windows Runtime products. They all stem from the same set of components but are different products in practice to the customers.
Each Release Train includes each supported version of these products. On average 20 to 25 final builds are produced with a single Release Train run.
1. Development
A typical changeset (feature or a bug), begins its journey in our product or support teams learning and discussing it with our customers. The related component team is also involved and begins working on their changes. Note that each component team is self-sufficient in running the integration tests against TAS before submitting those over to the Release team. The feedback loop otherwise would be horrendously long.
2. Submission
We catalog changes using GitHub issues. A GitHub issue includes all metadata relevant to the change and whether it's customer facing or not. It also includes a release note that comes into picture later. Importantly, each GitHub issue has multiple pull requests for each product version.
3. Feedback
We provide independent feedback to each pull request by running integration tests for that specific change. This produces a temporary but functionally equivalent build that allows the teams to debug and test their changes without blocking the main branch. This also includes any subjective feedback on the design, breaking changes, and compatibility problems between release and development teams.
4. Integration
Once the change is tested, the release team merges the change into the relevant product branch. The release team continues between providing feedback and integrating continuously. We integrate the changes to the upcoming release train.
5. Testing
Every other Friday, all integrated set of changes are fanned out into a testing matrix that includes testing TAS on IaaSes such as GCP, AWS, Azure, and vSphere platforms. Along with that, we test upgrades from the last patch and last minor versions of the product. We also have tests that check on backwards compatibility by making sure no unintended breaking changes are introduced.
Usually, this phase includes removal of changes that are failing the test suites with relevant feedback to the contributing team. We will record these as incidents and maintain a journal.
6. Publish
Once the test suite is green, the release conductor will initiate the pipeline to publish the artifacts to the Tanzu Network. Along with that, release notes are automatically compiled from GitHub issues and dependency diffs and are published to the Tanzu Docs website.