VMware Aria Automation Pipelines 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 deployed application on a Kubernetes cluster can use GitHub, Automation Pipelines, Doccker Hub, the trigger for Git, and Kubernetes.

When you use Automation Pipelines 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 Automation Pipelines with your existing development tools, the pipelines automate your entire DevOps lifecycle.

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

A 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 Automation Pipelines.

How Administrators use Automation Pipelines

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 Automation Pipelines.

Table 1. How Automation Pipelines 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 the additional resources under Getting Started with VMware Aria Automation.

Also see Tutorials for using Automation Pipelines.

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.

Automation Pipelines 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 Automation Pipelines, select the cloud proxy that resides in the same network as your endpoint.

To find out more, see Connecting Automation Pipelines 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 Automation Pipelines to endpoints.

Provide integrations with other services.

Ensure that integrations to other services are working.

To find out more, see VMware Aria Automation Documentation.

Create pipelines.

Create pipelines that model release processes.

To find out more, see Creating and using pipelines in Automation Pipelines.

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 Automation Pipelines.

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 Automation Pipelines.

Also, see How do I use custom dashboards to track key performance indicators for my pipeline in Automation Pipelines.

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 Automation Pipelines.

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 Automation Pipelines.

Also, see Setting up Automation Pipelines to model my release process.

Automation Pipelines is part of VMware Cloud Services.

  • Use Automation Assembler to deploy cloud templates.
  • Use Automation Service Broker to get cloud templates from the catalog.

To learn about other things you can do, see VMware Aria Automation Documentation.

How Developers Use Automation Pipelines

As a developer, you use Automation Pipelines 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 Automation Pipelines.

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 Automation Pipelines
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 . What is Automation Pipelines

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. Help icon that opens the In-Product Support panel in the Automation Pipelines user interface.

  • 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.