GoCD Reviews

The solution helps us deploy microservices across multiple environments.

GoCD's open-source nature is valuable. It is user-friendly as well. A key benefit is that it provides all the pipelines as code in one place, simplifying the creation of new pipelines by allowing you to reuse existing code and change the environment variables. 

Managing agents is also quite easy, as they can be enabled or turned off with just a few clicks, unlike in Jenkins.

One area of product improvement is the access control system. It is difficult to assign different access levels because it relies on separate keys for developer and admin access, which could be simplified. The folder structure is another aspect that could be enhanced, as all jobs are displayed on a single page without the clear organization seen in Jenkins. Implementing a more structured approach to organizing jobs would improve user experience.

AI could simplify job creation. For example, instead of manually editing pipelines as code, an AI tool could allow users to input variables and automatically generate the required jobs. It would help reduce human errors, such as issues that arise from incorrect edits in large code files.

I have been working with GoCD for three and a half years.

GoCD's specific features don't greatly differentiate it from Jenkins regarding deployment efficiency. The time and process for deployments are quite similar between both platforms.

We integrate the solution with Git, where we store our code. We use Maven to build the code and tools like SonarQube and Checkmarx for code quality checks. We deploy our services in a Kubernetes-based infrastructure using Helm Charts, and all the Helm and Docker commands are executed through GoCD.

It requires creating templates that can be reused in jobs. Most of the time, people prefer to use these templates, although creating jobs freestyle is possible. This differs somewhat from Jenkins, where job creation types are more defined. 

I rate it a seven out of ten. 

I worked for a company where we had pipelines to deploy new code and make changes in the existing infrastructure on GoCD. Another team maintains it. I was a user who used the solution to create and use the pipelines.

We can see all the pipelines with a simple search. The UI is colorful. The user experience is very rich. The product is very easy to learn if we know a bit of the basics. If we have someone to show us how to use it, it is very easy.

Jenkins is overtaking the product. The product must enhance user experience. Jenkins has everything in a simple XML format. However, GoCD is complex. Upgrading it to a simpler language would be helpful. The tool must be more user-friendly.

I have been using the solution for two years.

The tool was stable. We had some issues. Agents didn’t get allocated to the jobs that we ran. If I fire a job, an agent must be available to run the job. Sometimes, it took time for the agents to be allocated. Other than that, we didn't have any issues.

The tool was scalable. We could add users, give them permissions, and add jobs. When I used the solution in my organization, the company was trying to migrate most applications to Jenkins. We had around 200 users in the organization.

Jenkins is a bit faster and a bit enhanced than GoCD. So, my organization decided to switch to Jenkins.

The product is a bit outdated. Many modern tools like Jenkins and GitLab can replace GoCD. We have integrated the tool with GitHub for the repository and to get the pipelines working. The product is easy to use. If we have some basic knowledge about configuration management, it's a bit easy to understand the script. However, many other tools have the latest updates and enhancements. Overall, I rate the solution a six out of ten.

We are currently utilizing it for the integration aspect, specifically for the deployment phase of our project. To elaborate, we have a considerable number of Amazon EC2 instances, exceeding one hundred, and various code applications that interconnect with each other. For the deployment process, we rely on GoCD as our backend, and for the depositors, we utilize GoCD. Consequently, it forms an integrated set of GoCD.

Due to the fact that the code is written in core PHP, we have opted to use GOCD.

The most notable aspect is its user interface, which we find to be user-friendly and straightforward for deploying and comprehending pipelines. We have the ability to create multiple pipelines, and in addition to that, the resource consumption is impressive. 

The aspect that requires attention is the user management component. When integrating with BitLabs and authenticating through GitLab, there are specific features we desire. One important feature is the ability to import users directly from GitLab, along with their respective designations, and assign appropriate privileges based on that information. Allocating different privileges to users is a time-consuming process for us.

I would prefer to streamline the user management process, which would be more convenient for me. It would involve importing users from GitLab and granting them the necessary permissions they require.

I have been using GoCD for approximately five years.

The process of running our operation runs smoothly without any hiccups. It demonstrates exceptional performance even with minimal resources.

The solution is highly stable.

I rate the stability of GoCD a nine out of ten.

I have approximately 120 pipelines running on it. Remarkably, even with limited resources allocated, such as 4.2 GB of RAM and two virtual CPUs.

GoCD proves to be highly adaptable. If you have a project that doesn't require core PHP web integration, GoCD can efficiently handle long processes and tasks. However, for projects that involve integration, opting for CICD would be a better choice as it offers enhanced functionality in that regard. Additionally, I have successfully excluded shell scripts through GoCD for projects that require integration, and it seamlessly handles those as well.

All developers in our team, consisting of fifty individuals, utilize GoCD to monitor their core pipelines. It serves as a monitoring tool for both the development and testing environments, facilitating seamless integration and deployment.

I rate the scalability of GoCD an eight out of ten.

I have not used the support from the vendor.

The deployment of GoCD was a smooth process for us as we thoroughly reviewed the documentation. We encountered no difficulties or issues during the deployment, making it a seamless experience.

The initial setup of GoCD took us a day to go through the documentation and complete the basic configuration. However, comprehending the features and upgrading the system took us around ten to twelve days. It's worth noting that the learning process is ongoing and continuous, which I haven't covered in detail here. However, the setup alone took one day.

This is an open-source solution and it is inexpensive.

The reason behind our choice of GoCD is to have a deployment solution that enables us to effectively manage reports, assist with deployments, and handle versioning for our applications and websites. This is precisely why we have decided to utilize GitLab and GoCD together.

Initially, the primary consideration is the nature of the application software being used. The crucial question is whether the application software requires continuous integration (CI) or not. If the application software does not necessitate CI, then GoCD alone can suffice for managing deployments.

If your project does not require any integration or deployment complexities, specifically for code written in PHP, then GoCD would be the most suitable choice.

I rate GoCD an eight out of ten.

We use GoCD for the production environment and delivery needs, including Kubernetes container delivery.

In GoCD, you can effectively track sources and pipelines. The platform features pipeline groups that enable role differentiation, specifying who can perform which actions. Additionally, GoCD offers a valuable feature called the value stream map, which holds significant importance. The value stream map shows the complete flow of the pipeline itself, showcasing the input-output journey.

GoCD integrates seamlessly with various teams. For instance, it allows setting up top-level management access with read-only rights to monitor product deliveries, deployments, and the overall delivery process. Different teams, such as developers, QA, and testing teams, play crucial roles throughout these processes. With GoCD, you can easily track the success or failure of pipelines within different pipeline groups. This setup ensures that the QA team controls its pipelines and can modify them as necessary. In contrast, the development team cannot alter QA pipelines, maintaining segregation of responsibilities.

What sets GoCD apart is its transparency. Everything from pipeline status to progress is readily visible and accessible to all relevant parties, including management. This level of transparency eliminates the need for constant inquiries and allows stakeholders to access and understand the status of projects in real time. This transparency and accessibility are key attributes that make GoCD a precious and efficient project management and delivery tool.

GoCD could cover the authentication aspect. Currently, we are handling an in-house development that needs this. Comprehensive features must be established before transitioning into an enterprise product.

I have been using GoCD for four years. We are using the community version of the solution.

The product is stable.

I rate the solution’s stability a ten out of ten.

The initial setup is simple and takes about ten days to complete.

I rate the initial setup a ten out of ten, where one is difficult and ten is easy.

Deployment was done in-house.

The product is free of cost.

We spread the solution's maintenance to a team of five people and are covering more than 1500 users internally.

It was easy to learn and equally easy to reach developers, which was a pleasant surprise considering it's an open-source product. We could directly engage with developers, resembling having exclusive rights or a specialized contract. When posting an issue or seeking more information, they were highly responsive and eager to provide solutions, demonstrating a proactive and helpful approach.

Overall, I rate the solution a nine out of ten.

We use GoCD as our main Continuous Delivery (CD) pipeline tool. We integrated GoCD with Continuous Delivery tools, such as Jenkins and Team City.

We actively using the following features of the GoCD: LDAP integration, server-agents architecture (run GoCD agents on-demand in a Kubernetes cluster or on AWS EC2 instances to keep the operations cost low), plug-in architectures, Infrastructure as a code (pipelines in GoCD could be described in code repository).

Besides all these features, GoCD has a great UI with flexible permissions management. 

GoCD provides a good UI for development, QA, release, and management teams to be able to deliver new application versions in a transparent and predictable way.

We can setup GoCD to split the permissions between teams: the DEV environment is automatically updated, only the QA team could deploy the new version to the TEST environment, and only the management/release team can deploy new versions to the sensitive environment, such as UAT/DEMO/PROD.

We wrote the custom integration of the GoCD with Team City and Jenkins using the GoCD API and pipelines configuration files.

1. It has a user-friendly interface, which for free and open-source tools, the UI is really amazing and simple. It takes a few minutes to show the CD process to new users and onboard them.
2. Permission separations mean that we can grant limited permissions for each team or team member.
3. Integration with LDAP allows us to use central user management and leverage permission separation inside GoC.
4. Plug-in architecture gives us the ability to easily extend GoCD, although it is not always possible because of the limited number of plugins.
5. As an open-source solution, we always can check the issues, or rely on community support.

1. If the workflows were updated for any reason, such as when environments are created, deleted, or changed, the previous delivery pipelines will be broken. You can't redeploy the old version or propagate new versions to the following environments.
   
2. It would be great to have more flexibility in configuring the initial job. We are using GoCD for the CD process only, so any jobs are triggered by external CI tools, not the GoCD itself. We don't need to configure code repositories or other inputs that GoCD is expecting, so we are forced to create the dummy repository, and the commit history is not relevant to the CD process.
3. It would be great to have more available plug-ins to cover more functionality inside GoCD.
4. The documentation really should be improved by including real examples and more setup cases.

We have been using GoCD for between four and five years.

It's pretty scalable and you can run few deployments in parallel, depending on the number of available agents. You can scale manually or automatically.

We considered using Jenkins with custom plug-ins and TeamCity, but decided to use GoCD because it provides a better UX for CD.

I would advise using Azure DevOps if you are locked on Azure. Also, take a look at CircleCI, cloud GitLab CI, and BitBucket pipelines if you need a paid/all-in-one CI/CD solution. These tools also offer free and limited editions.

If you are interested in the features and an open-source solution, you can take a look at ConcourseCI or ArgoCD.

It's an open-source and free tool.

The Pipeline concept, Fan-in Fan-out, and Compare build are the most valuable to me.

We used to run our complex build process on TFS build and release manager, but its complicated license issue restricted us to roll it out to every team, and we always found a limited configuration for it to work as expected. After we switched to GO, each team can set-up their own delivery pipeline and run it themselves. Now, we have a completely automated product delivery process.

GO statistic and report options.

6 months.

No major issues.

So far so good.

No, we don't have any problem scaling our GO implementation from either infrastructure or team points of view.

Haven't had a need to call them.

Good documentation but not much community support compare to other CI/ CD tools

I used TFS build, Jenkins and TeamCity previously. We switched to GO because the pipeline concept promoted by GO is a good match with our process.

It's pretty easy, I got it done without any problems.

In-house, and all our developers take part in keeping their GO server running.

GO is open source, our initial cost is zero but it comes with a bit of learning curve so if your delivery process isn't that complex, I think other tools might give you better ROI.

Zero initial cost, and we host them on Azure, 8-9 VMs, at approximately $14 per day.

Go was our winner when evaluated, along with Jenkins, TFS build, Atlassian Bamboo and Team City.

GO doesn't come with a lot of out of the box features like other tools, don't expect that you can get it to work by clicking the NEXT button.

Hackability, visual representation of build pipelines, open source Apache License 2.0

Before implementing Go we used librarian-puppet to deploy code to different Puppet master servers. With Go we were able to automate that process, implement extra code checking functionality and get a nice visual view of our environments state.

User management, Documentation, Advanced GUI functionality.

6 months

Nothing which was Go's fault.

No stability issues.

We have just one Go server and haven't looked into scalability yet.

We used the online community only and hence cannot comment on this.

We used the online community only and hence cannot comment on this.

We used librarian-puppet. We switched because of greater automation, transparency and manageability of deploying our Puppet code through our environments.

It was straightforward because there are online resources on how to do it.

In-house team.

The product is free to use. In terms of value added it has more than achieved everything we wanted from it and more.

Setup cost was 1 week's time of one of our team member.

Jenkins.

Try out alternatives and pick the one which fits you the best.