About Jenkins

Jenkins

Jenkins - Features

• Installation is more flexible than Go (Go is tied to Jetty and comes with it, but can be fronted with some other web server. Jenkins is not tied to any web server).
• Extensibility. Plugins - About 600 of them.
• Slightly easier to get started since it can work in “master-only mode”, where there is no slave node (“Agent” installation is a must in Go). 
• Integration with VCS: Almost everything you’ve heard of and some you haven’t, because of plugins.
• First class and often deep support for many tools: Maven (reads POM to figure out dependencies), Rake, Vagrant, Debian package building
• Well-known. Community is pretty good, especially plugin writers.

Jenkins - Missing features (compared to Go)

• Modelling capability is limited. While there are options to model in parallel-serial-parallel-serial approach using plugins, it is not very convincing. Support for multiple VCS for a job is supported through plugins which makes implementing a feature like fan-in difficult (plugin for fan-in will need to talk to VCS plugins)
• Visualization and VSM - End-to-end visualization and auditability not at the level of Go. [how-to-use-jenkins-for-job-chaining-and-visualizations]
• Fan-in: Jenkins does build incompatible builds resulting in lots of wasted build time. All the literature around the build flow plugin is still not convincing enough to say that it supports fan-in.
• Go security seems more fine-grained than Jenkins’. Go allows per-user/group and per-pipeline authorization. Jenkins seems to allow this only at a global, per-user/group level.

Go CD VS Jenkins

1. Go CD is a best-of-breed tool for Continuous Delivery (CD).

    Jenkins is a general purpose automation tool and is built for Continuous Integration(CI).

2. Go CD aims to support the most common CD scenarios out of the box without any plugin installation where as Extensibility is core to Jenkins. Its flexibility attributes itself to plugins being critical to Jenkins’ functionality. So it depends heavily on plugins for pretty much any use case.

3. Go CD was built on the principles of [Continuous Delivery](https://continuousdelivery.com/). This is visible in its abstractions as pipeline is a first class concept. Go CD also encourages that there be only one way to implement the fundamental CD patterns. When you search for help on how to implement the various deployment pipeline patterns, you will generally find a single, well-known, well-tested answer.

With Jenkins 2.0, CD is implemented by the installation of a variety of plugins. Many common CD patterns (build an artifact only once, full traceability up and down stream, and more) are either impossible to implement or can only be cobbled together with fragile   combinations of plugins.

4. Although Go CD is built specifically with CD in mind, it has sophisticated features for continuous integration.

Jenkins is built for CI. Anything beyond that, requires plugins.