Last updated on Nov 07, 2023
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!
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.
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.
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.
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".
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-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.
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 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.
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.
An "environment" within the GoCD is a means of grouping and isolating pipelines and agents. The rules of the environment are as follows:
In addition to environment matching restrictions, resources must match between jobs and agents, as described in the Resources section.
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.
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.
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.
As a Senior Writer for HKR Trainings, Sai Manikanth has a great understanding of today’s data-driven environment, which includes key aspects such as Business Intelligence and data management. He manages the task of creating great content in the areas of Digital Marketing, Content Management, Project Management & Methodologies, Product Lifecycle Management Tools. Connect with him on LinkedIn and Twitter.
|Batch starts on 6th Dec 2023||
|Batch starts on 10th Dec 2023||
|Batch starts on 14th Dec 2023||