VMware Code Stream™ is a continuous integration and continuous delivery (CICD) tool. By creating pipelines that model the software release process in your DevOps lifecycle, you build the code infrastructure that delivers your software rapidly and continuously.

The workflow from a code check-in to a deployed application on a Kubernetes cluster can use GitHub, Code Stream, Docker Hub, the trigger for Git, and Kubernetes.

When you use Code Stream to deliver your software, you integrate two of the most important parts of your DevOps lifecycle: your release process and your developer tools. After the initial setup, which integrates Code Stream with your existing development tools, the pipelines automate your entire DevOps lifecycle.

Starting in September 2020, Blueprints are called VMware Cloud Templates.

You create a pipeline that builds, tests, and releases your software. Code Stream uses that pipeline to progress your software from the source code repository, through testing, and on to production.

A VMware Code Stream pipeline continuously integrates and delivers applications from the code in the development repository, through build tests, acceptance tests, and deployed to production.

You can learn more about planning your continuous integration and continuous delivery pipelines at Planning to natively build, integrate, and deliver your code in VMware Code Stream.

How Code Stream Administrators use Code Stream

As an administrator, you create endpoints and ensure that working instances are available for developers. You can create, trigger, and manage pipelines, and more. You have the Administrator role, as described in How do I manage user access and approvals in Code Stream.

Table 1. How Code Stream Administrators support developers
To support developers... Here's what you can do...
Provide and manage environments.

Create environments for developers to test and deploy their code.

  • Track status and send email notifications.
  • Keep your developers productive by ensuring that their environments continuously work.

To find out more, see More resources for VMware Code Stream Administrators and Developers.

Also see Tutorials for using VMware Code Stream.

Provide remote, on-premises endpoints.

Ensure that developers have working instances of remote, on-premises endpoints that can connect to their pipelines.

When a developer needs to connect their pipeline to a remote, on-premises endpoint, you need to download and install the cloud proxy. The on-premises endpoint communicates through the proxy to provide data for the pipeline to run.

Code Stream connects to endpoints on premises through a cloud proxy. Your network configuration and the location of your endpoints on premises in those networks determine how many cloud proxy instances you need. If all your endpoints on premises are in the same network, install a single cloud proxy. If your endpoints on premises reside in different networks, install one cloud proxy for each independent network. Then, in the endpoint configuration in Code Stream, select the cloud proxy that resides in the same network as your endpoint.

To find out more, see Connecting VMware Code Stream to endpoints.

Provide cloud-based endpoints.

Ensure that developers have working instances of cloud-based endpoints that can connect to their pipelines.

To find out more, see Connecting VMware Code Stream to endpoints.

Provide integrations with other services.

Ensure that integrations to other services are working.

To find out more, see vRealize Automation Cloud documentation.

Create pipelines.

Create pipelines that model release processes.

To find out more, see Creating and using pipelines in VMware Code Stream.

Trigger pipelines.

Ensure that pipelines run when events occur.

  • To trigger a standalone, continuous delivery (CD) pipeline whenever a build artifact is created or updated, use the Docker trigger.
  • To trigger a pipeline when a developer commits changes to their code, use the Git trigger.
  • To trigger a pipeline when developers review code, merge, and more, use the Gerrit trigger.
  • To run a standalone continuous delivery (CD) pipeline whenever a build artifact is created or updated, use the Docker trigger.

To find out more, see Triggering pipelines in VMware Code Stream.

Manage pipelines and approvals.

Stay up-to-date on pipelines.

  • View pipeline status, and see who ran the pipelines.
  • View approvals on pipeline executions, and manage approvals for active and inactive pipeline executions.

To find out more, see What are user operations and approvals in VMware Code Stream.

Also, see How do I use custom dashboards to track key performance indicators for my pipeline in VMware Code Stream.

Monitor developer environments.

Create custom dashboards that monitor pipeline status, trends, metrics, and key indicators. Use the custom dashboards to monitor pipelines that pass or fail in developer environments. You can also identify and report on under used resources, and free up resources.

You can also see:

  • How long a pipeline ran before it succeeded.
  • How long a pipeline waited for approval, and notify the user who must approve it.
  • Stages and tasks that fail most often.
  • Stages and tasks that take the most time to run.
  • Releases that development teams have in progress.
  • Applications that succeeded in being deployed and released.

To find out more, see Monitoring pipelines in VMware Code Stream.

Troubleshoot problems.

Troubleshoot and resolve pipeline failures in developer environments.

  • Identify and resolve problems in continuous integration and continuous delivery environments (CICD).
  • Use the pipeline dashboards and create custom dashboards to see more. See Monitoring pipelines in VMware Code Stream.

Also, see Setting up VMware Code Stream to model my release process.

Code Stream is part of vRealize Automation Cloud. Code Stream integrates with:

  • Use VMware Cloud Assembly to deploy cloud templates.
  • Use VMware Service Broker to get cloud templates from the catalog.

To learn about other things you can do, see VMware Code Stream Documentation.

How Developers Use Code Stream

As a developer, you use Code Stream to build and run pipelines, and monitor pipeline activity on the dashboards. You have the User role, as described in How do I manage user access and approvals in Code Stream.

After you run a pipeline, you'll want to know:

  • If your code succeeded through all stages of the pipeline. To find out, observe the results in the pipeline executions.
  • What to do if the pipeline failed, and what caused the failure. To find out, observe the top errors in the pipeline dashboards.
Table 2. Developers who use Code Stream
To integrate and release your code Here's what you do
Build pipelines.

Test and deploy your code.

Update your code when a pipeline fails.

Connect your pipeline to endpoints.

Connect the tasks in your pipeline to endpoints, such as a GitHub repository. Cloud-based endpoints, and remote endpoints on premises, provide data for your pipeline to run.

Run pipelines.

Add a user operation approval task so that another user can approve your pipeline at specific points.

View dashboards.

View the results on the pipeline dashboard. You can see trends, history, failures, and more.

For more information about getting started, see Getting Started with VMware Code Stream.

Find more documentation in the In-product Support panel

If you don’t find the information you need here, you can get more help in the product.

  • Click and read the signposts and tooltips in the user interface to get the context-specific information that you need where and when you need it.
  • Open the In-product support panel and read the topics that appear for the active user interface page. You can also search in the panel to get answers to questions.

More on Webhooks

You can create multiple webhooks for different branches by using the same Git endpoint and providing different values for the branch name in the webhook configuration page. To create another webhook for another branch in the same Git repository, you don't need to clone the Git endpoint multiple times for multiple branches. Instead, you provide the branch name in the webhook, which allows you to reuse the Git endpoint. If the branch in the Git webhook is the same as the branch in the endpoint, you don't need to provide branch name in the Git webhook page.