GoCD Tutorial

What is GoCD?

GoCD is an open-source tool for software development that assists teams and organizations in automating the continued delivery of software. It supports the automation of the whole build-test-release process, from check-in of code to deployment. It allows you to continue to produce valuable software in the short run and to make sure that the software can be released reliably at all times. It supports a variety of version control tools like Perforce, Mercurial, Git, Subversion, and TFVC. Other version control softwares may be supported with the installation of extra plugins. GoCD is available under Apache 2 license.

Interested in learning the GoCD Course? Enroll in our GoCD Online Training program now!

Features of GOCD:

• Parallel and sequential execution makes it easy for GoCD to configure dependencies for quick feedback and on-demand deployment. 
• Visibility in the end-to-end workflow. In an instance, track the modification from commit to deploy.
• It is easy to pass binaries between stages when built.
• Manual triggers permit the deployment of any release at any time. And that's safe and auditable.
• Executes tests written in most languages or frameworks and delivers an informative test report.
• Compare the two files and the propagation messages among two arbitrary builds.
• Eliminate bottlenecks by offering a trivial parallel performance between platforms, pipelines, industries, versions, etc.
• GoCD features extension points where plugins can be created.
• Reuse pipeline configurations with ease through a template system.

Concepts in GOCD:

Server and Agents:

In the GoCD ecosystem, everything is controlled by the Server. It offers the UI to system users and gives work to agents. Agents are those who perform any work like the execution of commands, deployment, etc. It is configured by the system administrators or users. The Server does not perform any work by itself. It doesn't run any commands or does deployments. Therefore, you need to install a GoCD server and at least one GoCD Agent before proceeding.

Stages, Jobs and tasks:

A pipeline contains one or more stages. Every stage contains one or more jobs. Each job contains one or more tasks. All these elements are modelling constructs in a pipeline.

Task: A task is usually a command that is configured to be executed for the task within which it is located. Each task does not need to be just a command, as tasks can be plugins. GoCD has Rake, Ant and NAnt tasks as integrated tasks. It even has plenty of optional plugins that may be installed. A task is an action that should be executed. Generally, it is just a single command.

Job: A job is a sequential set of tasks. Every task in a task is executed one at a time, and in its default configuration, when a task fails, none of the following tasks is executed. The job is therefore considered to have been "unsuccessful". The most important thing about a job is that only one Agent is required to collect and complete a job. You can therefore have the guarantee that all the tasks of a job are carried out by the same Agent. Each task of work is performed as an independent program, and therefore, modifications performed by a task to one of its environmental variables will not impact the next tasks. Any modification carried out by a task on the file system will be visible for the following tasks.

Stage: A stage is a set of jobs that are not sequential. They can be collected in any order, and therefore they must be independent of one another. This crucial difference between the way a job is made up of its tasks (sequential) and the way a stage is made up of its tasks (non-sequential) is what provides the parallelization built into the GoCD. All the jobs in a stage are independent of one another. So all the jobs will be started when the stage starts. Suppose you have enough agents and they are not busy, then each job in a stage can run on different agents simultaneously, which will speed up your build a lot. The success or failure of one job shall not have an impact on the success or failure of the other job.

Pipelines and Materials:

In GoCD, a pipeline represents a workflow or a portion of a workflow. It is possible to configure a pipeline to perform a command or a set of commands. For example, if you attempt to carry out the tests automatically, then build an installer, deploy the application to the test environment. These steps are modelled like a pipeline. GoCD delivers various modelling structures across a pipeline, like jobs, tasks and stages.

Another important concept is Material. A material causes a pipeline to "trigger" or begin to do what it is designed to do. Generally, Material is a source control repository such as Subversion, Git, etc. Any commit to this repository is the cause to trigger the Pipeline. A pipeline requires one or more materials and may have different types of materials as you wish. The Pipeline is the core concept of Continuous Delivery. With stages, tasks and jobs concepts, GoCD delivers important modelling blocks that enable you to build highly complex workflows and get faster feedback.

Material and triggers:

A material causes the operation of a pipeline. Generally, this is a repository of source code material like Git, Mercurial, SVN, etc. The GoCD Server monitors the configured materials continuously, and when it finds a new change or commit, the pipelines related to it are executed or "triggered".

Pipeline Dependency Material:

Materials actually start to become strong when one step of a pipeline is used as a material for another pipeline. For example: Assume there are two pipelines. Two stages in the first Pipeline and three stages in the second Pipeline. Consider Stage two in the first Pipeline is configured as the materials for stage one of the second Pipeline. Then when stage two of the first Pipeline is successfully completed, then the second Pipeline is triggered. Here the first Pipeline is known as the Upstream Pipeline, and the second Pipeline is known as the Downstream pipeline, and stage two of the first Pipeline is known as Upstream dependency of the second Pipeline.

Any stage in a pipeline may serve as a material. For example: consider, Stage one in the first Pipeline is configured as the materials for stage one of the second Pipeline. When stage one of the first Pipeline is successfully completed, then Pipeline two is triggered. Now stage two of the first Pipeline and stage one of the second Pipeline will be executed at the same time.

Fan-In and Fan-Out:

Fan-Out: It is said that a material is "fan-Out" to downstream pipelines when the completion of the Material in one Pipeline triggers several downstream pipelines. The reason for a fan-out does not necessarily need to be a pipeline-dependent material. It could be any kind of Material.

Fan_In: It is said that a material is "fan-In" when there is a requirement of several upstream materials to trigger the downstream Pipeline. An interesting and important thing of fan-In is that the GoCD will make sure that upstream pipeline revisions are consistent prior to triggering the downstream Pipeline. For example: Consider that stage one in the first Pipeline and stage two in the second Pipeline are configured as the materials for the third Pipeline. If stage one of the first Pipeline is very slow and stage two of the second Pipeline has been completed, then the third Pipeline will wait for the first Pipeline to be completed before it is triggered. It will not be triggered with the previous or inconsistent revision of the first Pipeline, as just the second Pipeline was completed quickly. 

Artifact:

In GoCD, an artefact is a file or folder that is usually generated during the execution of a pipeline. Each job on a pipeline may be configured so that it can publish its own collection of artefacts, and GoCD will make sure those artefacts are moved from the Agent where they were created and stored to the Server so that they may be retrieved at any time. In general, artefacts are generated during a job through one of the tasks. Examples of artefacts include coverage reports, test reports, documentation, installers, meta information on the build process and everything that should be stored once the Pipeline is completed. These artefacts, published through a job, may be retrieved and used by any of the downstream pipelines or any stage following the stage in which the Artifact occurred in the same Pipeline, with the help of a special task known as the "Fetch Artifact" task. 

Fetch Artifacts: GoCD offers a special task known as "Fetch Artifact Task", which makes it possible to retrieve and use artefacts from any of the ancestor pipelines that refers to any pipeline above the existing Pipeline. GoCD will make sure that the accurate version of the Artifact is retrieved, regardless of what is happening in the system.

Value Stream Map:

Value Stream Map is a complete view of a pipeline, pipelines downstream it will trigger and its upstream dependencies. When deciding what pipelines to trigger, the GoCD fan-in and fan-out resolution will handle all dependencies in a coherent way. In GoCD, Pipeline, Pipeline dependency and Artifact to allow a true end-to-end deployment pipeline called Value Stream Map.

Resources:

Agents and jobs may be improved with "Resources". Resources are free tags, which assist Go in deciding which agents are able to pick up a particular job. Resources may be considered to be the Agent broadcasting its capabilities. Resources are set by admins and may mean everything that admins want them to mean. In such a case, it may be an indication that the Agent installed Firefox to execute functional tests and that it is a Linux box. Resources become very helpful when you put resources into jobs. For jobs, resources can be considered as the capabilities an agent needs to function successfully.

Environment:

An "environment" within the GoCD is a means of grouping and isolating pipelines and agents. The rules of the environment are as follows:

• A pipeline may be associated with as many environments as possible.
• An agent may be linked to more than one environment or none.
• An agent can collect jobs related to the pipelines in environments in which they are associated.
• An agent related to an environment cannot take jobs from pipelines that have no associated environment.

In addition to environment matching restrictions, resources must match between jobs and agents, as described in the Resources section.

Environment Variables:

Environment variables are frequently thought of as "Environments". They are not directly associated. In GoCD, "Environment Variables" are defined by the users during the configuration. The environment variables are provided to the tasks in the same way as other environment variables that are available to processes when running in an operating system. Environment variables may be defined on several levels like in pipelines, in environments, in jobs and in stages. They follow a cascading system in which the environment variables are set to the "Environment" level and are overridden by environment variables that are defined at the pipeline level, etc.

Templates:

Templating makes it possible to create workflows that can be reusable to ease tasks such as the creation and maintenance of branches and the management of a large number of pipelines. Pipeline templates are manageable under the Templates section of the Admin menu.

Conclusion:

In this post, we have covered the information about GoCD, features of GoCD and the concepts related to GoCD like Server and Agents, stages, jobs, tasks, environment, environment variables, Value Stream Map, resources, Artifact, fan-In, fan-Out, etc. I hope this information helped you in learning about GoCD.