Investigating the suitability of GoCD for software automation use cases
Heikkinen, Johannes (2021)
2021
All rights reserved. This publication is copyrighted. You may download, display and print it for Your own personal use. Commercial use is prohibited.
Julkaisun pysyvä osoite on
https://urn.fi/URN:NBN:fi:amk-202104154905
https://urn.fi/URN:NBN:fi:amk-202104154905
Tiivistelmä
The current approaches to modern software development place a lot of emphasis on automation, either by automating the steps in how software finds its way to an end user, or the activities that help in making the software development software process itself more efficient and less prone to human error.
More complex use cases for software automation require more from the tools used to manage these processes. Traditionally, Jenkins has been the most popular continuous integration tools, but its underlying architecture was designed in the early 2000’s, and it was not originally designed with the modern use cases in mind. Non-functional requirements, for example automation of the tool itself or user experience, have evolved as well.
One modern competitor for Jenkins is GoCD. GoCD is a continuous delivery tool that is based on the CruiseControl automation tool and was originally released by ThoughtWorks in 2014. It is an open source tool based on Java and JRuby on Rails and is designed for complex workflows that can be defined as code.
This thesis is an investigation about the suitability of GoCD for a selection of use cases in modern software automation related to either Continuous Integration, automation that otherwise aids in software development, or automation of the tool itself. The aim is to establish an understanding on its suitability to some of the most common and critical workflows, and to understand whether the tool is suitable for modern software automation needs in general.
The use cases were selected to represented a variety of real life situations in software automation, and were tested to the extent that it could be judged how well GoCD enabled the use case and whether there were problems with it. The use cases selected have been roughly divided into several different themes, and were examined roughly in the order they might be encountered in software projects.
The official GoCD documentation was consulted during the thesis, but the use cases were still tested out with scenarios that simulate ones encountered in real software projects, to see whether they are actually supported at the time of writing. The use case examination touched on concepts such as continuous integration and infrastructure as code to see if they are sufficiently enabled by the tool, without going into details or best practices regarding them.
GoCD was found to adequately support most of the use cases examined, but there were some notable exceptions. It is designed with a trunk-based source control workflow in mind and support for other approaches is either non-existent or limited, which can be a critical issue. Moreover, the quality of the official documentation was found to be uneven and it was sometimes lacking or confusing, which can be a hindrance.
Overall, based on the results GoCD could be useful in organizations that are not planning to use anything other than a trunk-based workflow, provided that the other lacking features or its opinionated architecture are not a concern. As some use cases require cumbersome workarounds and the quality of the official documentation cannot be fully relied upon, already existing knowledge of GoCD in the organization would be beneficial before taking it into use.
More complex use cases for software automation require more from the tools used to manage these processes. Traditionally, Jenkins has been the most popular continuous integration tools, but its underlying architecture was designed in the early 2000’s, and it was not originally designed with the modern use cases in mind. Non-functional requirements, for example automation of the tool itself or user experience, have evolved as well.
One modern competitor for Jenkins is GoCD. GoCD is a continuous delivery tool that is based on the CruiseControl automation tool and was originally released by ThoughtWorks in 2014. It is an open source tool based on Java and JRuby on Rails and is designed for complex workflows that can be defined as code.
This thesis is an investigation about the suitability of GoCD for a selection of use cases in modern software automation related to either Continuous Integration, automation that otherwise aids in software development, or automation of the tool itself. The aim is to establish an understanding on its suitability to some of the most common and critical workflows, and to understand whether the tool is suitable for modern software automation needs in general.
The use cases were selected to represented a variety of real life situations in software automation, and were tested to the extent that it could be judged how well GoCD enabled the use case and whether there were problems with it. The use cases selected have been roughly divided into several different themes, and were examined roughly in the order they might be encountered in software projects.
The official GoCD documentation was consulted during the thesis, but the use cases were still tested out with scenarios that simulate ones encountered in real software projects, to see whether they are actually supported at the time of writing. The use case examination touched on concepts such as continuous integration and infrastructure as code to see if they are sufficiently enabled by the tool, without going into details or best practices regarding them.
GoCD was found to adequately support most of the use cases examined, but there were some notable exceptions. It is designed with a trunk-based source control workflow in mind and support for other approaches is either non-existent or limited, which can be a critical issue. Moreover, the quality of the official documentation was found to be uneven and it was sometimes lacking or confusing, which can be a hindrance.
Overall, based on the results GoCD could be useful in organizations that are not planning to use anything other than a trunk-based workflow, provided that the other lacking features or its opinionated architecture are not a concern. As some use cases require cumbersome workarounds and the quality of the official documentation cannot be fully relied upon, already existing knowledge of GoCD in the organization would be beneficial before taking it into use.