Skip to main content
System StatusContact Support
VersionOne Community

Setting Up a Simple Continuum Pipeline

Overview 

This article walks you through the process of setting up a simple Continuum pipeline that integrates with tools in your organization.

It is advised that you look over this prerequisites and make sure you have everything ready to go before starting.

The basic path for the tutorial will be to get Changes from you source code management system into Continuum then relate those changes with what we call work items or tickets in an issue management or ALM system. Then these Changes and Work Items can be submitted to a delivery pipeline which will run them through a continuous integration platform for the build process and then possibly deployed to an environment for testing.

The tutorial will start small and build up over successive steps.

Prerequisites

Before starting with the guide you will want to gather some information and plan which tools to use in your organization. Read this section all the way through before making any final decisions.

Source Code Project and Repository

First select a software development project in a source control repository that you have access to and can make changes / commits to. It may be preferable for this tutorial to make a fork, copy or a throw-away branch so that there is no impact to current development. You will also need to gather credentials that allow you to make commits / pushes as well as potentially configure "webhooks" that push a change notification to the Continuum REST API. Sometimes these configurations require administrative level access to the project in the SCM.

The following SCMs are supported in this tutorial:

  • Bitbucket

  • GitHub

  • GitLab

  • Subversion

  • Team Foundation Server (TFS)

If your organization has another SCM provider please contact support@versionone.com to check and see if we have a solution for you.

Issue Tracking/ALM

Presumably the software project selected has a related issue tracking system. Preferably all change (commits) made are related to an issue, what we call a work item. When a change is pushed into Continuum the related work item will be associated with the change and get tracked throughout the delivery process.

At minimum credentials that have read-only API access to the project in the issue management system will be required. Optionally the credentials can have update access that Continuum would use to add comments or update issue status, etc. You will probably want to create a handful of issues / tickets for the project that will be used for the tutorial and that can be canceled later.

The following issue tracking / ALM systems are currently supported in this guide:

  • VersionOne Lifecycle

  • Atlassia Jira

  • Team Foundation Server (TFS)

Contact support@versionone.com if you are using another issue tracking system.

Continuous Integration / Build Service

Most software development projects rely have a build or compile process or some other process that assembles the project into a deliverable. As part of the Continuous Delivery pipeline we will want to have Continuum integrate with this tool and kick off this build process.

Credentials will be needed that have the ability to launch builds and read the results. If there is an existing build definition in place, for the purposes of the tutorial you may want to copy it so as to not interfere with existing development.

The following Continuous Integration platforms are currently supported in this tutorial:

  • Bamboo

  • Jenkins

  • TeamCity

Contact support@versionone.com if you are using another build system.

Notification Service

Optionally you may want to turn on notifications either via email or through a group collaboration tool such as HipChat or Slack. For email you will need to define the SMTP settings for the Continuum Messenger. For HipChat or Slack you will typically need API keys and "rooms" to post the messages to. For SMTP email messages you will need to acquire SMTP server host address, port and credentials.

Deployment Considerations

Part of the Continuous Delivery process should include an automated deployment component as part of the delivery pipeline. This is typically to a prebuild test environment, or could be to ephemeral cloud based environments. Continuum Deploy can handle both scenarios.

If deploying to virtual infrastructure that you want Continuum to manage starting and terminating, then you will need to acquire credentials or API keys that will be used to talk to the cloud API endpoint. You will also need to gather the existing steps to install, config and test your application whether they are currently manual or already automated.

Windows

Some of the additional Windows considerations:

  • Setting up Winrm on a server if not already done

  • Local credentials to that server with remote scripting enabled or setting up Kerberos on the Continuum server for authenticating domain accounts on target systems

  • Learning enough PowerShell to prove that automated deployment and configuration of your application can be successful in your environment

Continuum support can help you if you need assistance in some of these areas.

Linux

Linux considerations:

  • Credentials for and Linux infrastructure which may include user ids or password or ssh private keys

Virtual Infrastructure

Continuum currently supports the following virtual infrastructure APIs. Contact support@versionone.com if you have other needs

  • Amazon AWS

  • VMware vCloud

  • VMware vCenter

  • VMware vSphere

  • Digital Ocean

  • Eucalyptus

  • OpenStack (via EC2 compatibility API)

  • Apache CloudStack (via EC2 compatibility API)

Other virtual infrastructure considerations:

  • Find out the names of the images / vApps (vCloud, VMware vCenter) that will be used

  • Get any cloud API keys or credentials that Continuum can use to manage the virtual machines

Next

Continue with the next step Installing Continuum.

  • Was this article helpful?