Jenkins

As a new user that jumped into Jenkins, it seemed a bit more overwhelming to use at first. If there was an intuitive guide that could help out the workflow would be great.

It took a little elbow grease to get Jenkins to cooperate with Git.

When builds fail, I wish it would give a little bit more detail in troubleshooting what went wrong.

Jenkins provides a 'pipeline' where a user can fine tune instructions for Jenkins to execute. This pipeline is hard to use via the browser as it cannot be resized.

UI Interface

API

Administration

Difficult to manage build configurations: builds are generally configured through the user interface, which is easier to modify (especially for casual users rather than dedicated release engineers), but this results in changes that can be difficult to track, especially if multiple people have write access to the system. Some teams manage this by restricting people that can modify builds, but this creates a bottleneck. Ideally, the system would provide a good audit trail and change history, allowing changes to be tracked and reverted easily. Competing offerings get around this by version-controlling their configuration (e.g. Travis CI, Drone, AppVeyor) but this results in a slightly higher learning curve.

Quality of plugins varies widely: plugins are in various states of maintenance, and some are woefully incomplete and no longer updated. It can be difficult to know whether a plugin is well-written or not, or even actively maintained.

Builds are often not easily reproducible: By default, builds are run on the slave systems, which can retain state between runs that cause difficult-to-debug failures. It's possible to get around this by using VM snapshots and periodically reverting to clean systems, or by using the Docker plugin to run builds inside ephemeral containers.

Plugins are globally scoped: Because plugin versions and the Jenkins version are per-installation, companies with multiple teams typically run multiple instances of Jenkins. This leads to a maintenance nightmare and a lot of duplicated effort across teams keeping the systems patched, but is necessary because software requires different toolchains. It would be nice if Jenkins supported plugins on a "per tenant" basis, even though the running version would still be one-per-instance. Some platforms (such as OpenShift) get around this by running Jenkins inside a container, but that leaves out Windows slaves.

Unfortunately, Jenkins does not have integration with all major software services. This is because it is open source and the community itself will create and publish various plugins to allow Jenkins to interface with these other services, but this means that for a specific service either we wait for the plugin to be available or we must develop our own.

Jenkins can be used on various operating systems, although it is not simple to use or configure a heterogenous Jenkins solution (where master node and/or worker nodes have different OSs).