What is your favorite CI/CD tool and why?

Comments

[Devin Handspiker-Wade]

GitLab-CI:

• Supports Docker containers, SSH, or virtual machines
• Easy to configure YAML
• Can self-host a runner while also providing a free shared runner for smaller projects
• Can be used for non-Gitlab projects
• Config is tracked in the repo
• Files can be cached between runs based on a dynamic key
• Jobs can be tested locally before committing the config
• Can run jobs based on the branch or tag pushed
• Job can be scheduled to run on a regular basis
• Provides artifact storage (As far as I know Bitbucket doesn't)

[Evan Oman]

Very cool, we just got Gitlab Enterprise at work (after sitting on Gitlab 6 for years) and I am excited to try the CI stuff out.

[Devin Handspiker-Wade]

Do you mean "...sitting on Github"? 'Cause CI access is included even in the free GitLab packages.

[Evan Oman]

Hmm, yeah our local Gitlab instance only has the Git part available as far as I can tell.

[Sten]

Bitbucket Pipelines:

1. It's bundled with Bitbucket, no need to bring another tool
2. Supports Docker out of the box
3. Allows me to use the same commands as the one I run in my terminal
4. Supports different forms of deployment pipelines

But I'm biased since I was the lead product manager for it back when I was at Atlassian 😅 (still think the team did a stellar job - and it's great to watch it grow from the sidelines now).

[Kodengo]

The pipeline config is close to the code which makes it visible and accessible to the devs. This makes the pipelines more dev-ish than some pipeline scripts that sit in another repo that I cannot even access and are maintained by an ops guy that sits in an office 3 buildings away...

[Pavan Belagatti]

Even I like Bitbucket but what I don't like is the outdated UI and it is a bit confusing.

[Dian Fay]

I've had a love/hate thing going with Jenkins for about a decade now. It's fantastically powerful but an absolute bear to use.

[Kodengo]

Jenkins - The swiss army knife of CI tools.
I like the options they now have to represent pipelines as code. That way you can define maintain and scale the build definitions in code and have them versioned with your project.

[Pavan Belagatti]

Same here, I have a love/hate relationship with Jenkins.

I like Jenkins because,

• So many plugins
• versatility
• Super nice integration with Github or Bitbucket
• The pipeline as code is wonderful
• The declarative pipeline is good

I hate Jenkins because,

• Harder time understanding the point and click nature of Jenkins
• Many of them think 'it's not a modern CI' tool.
• can't write logic for your pipeline because the tool your using had its own logic
• Documentation is not at all good
• Its configuration(the server) cannot be defined as code which is a pain to manage plugins, credentials, etc
• Declarative is amazing, but the lack of documentation makes you insane because you only find info for scripted pipelines
• There's an annoying bug that doesn't let you save the project configuration in a github organization.
• UI looks awful *The API is horrendously, staggeringly bad
• There's no good way to handle multi-branch projects

I prefer CircleCI, Codeship or Shippable.

[Dian Fay]

I was actually pretty happy with multibranch pipelines at my last job! The only problem is the same problem with pipelines in general -- poorly documented Groovy APIs and script approvals.

[Evan Oman]

poorly documented Groovy APIs

So true! I was just trying to do something very simple and I couldn't find any info on how to interact with plugins (eventually figured it out by modifying an example).

[Dian Fay]

It's really amazing that in 2018 the way you get your coverage report in Pipelines is still

step([
  $class: 'CoberturaPublisher',
  autoUpdateHealth: false,
  autoUpdateStability: false,
  coberturaReportFile: '**/cobertura-coverage.xml',
  failUnhealthy: false,
  failUnstable: false,
  maxNumberOfBuilds: 0,
  onlyStable: false,
  sourceEncoding: 'ASCII',
  zoomCoverageChart: false
])

because there isn't a proper step defined.

[Patricio Cano]

Shameless plug: I created a new CI/CD tool called AlloyCI.

It is written in Elixir, and is heavily based on GitLab CI. It, in fact, can use the GitLab CI Runner as an executor for all the jobs. It also provides its own runner, that is a fork of GitLab's.

For the time being it is still in beta, but the main goal is to make it a viable option for people looking for a new CI tool.

As of right now, it has about 85% of the functionality that GitLab CI has, configuration is written in JSON (but we are thinking about transitioning to YAML), and it should be pretty straight forward to install and use. We provide Docker Images to get started quickly, and also a "Deploy to Heroku" button to try it out there too.

The main use for AlloyCI is to install it on premises, and add as many runners as you need. Since the runners are written in Go, binaries are available for all platforms. It supports Docker, Docker+Machine, SSH, VirtualBox, and Shell as ways to execute your builds.

With Docker+Machine you can have auto-scalable runners, e.g. one machine is in charge of deploying and destroying other runners. This works great with Digital Ocean. Runners will be created as needed, and everything about how many are created, how long they stay up, and more can be easily configured.

Since it is written in Elixir, it consumes very little system resources, it's highly stable, and should be able to process large amounts of concurrent requests.

I would love it if you could give it a try, and tell us what you like, what you don't like, what you hate, what you love, etc.

We really want to make AlloyCI a true alternative ❤️

[Pavan Belagatti]

Nice. Yes, transitioning to YAML is a good option, it makes the tool easy to use. All the very best:)

[Dimitri Merejkowsky]

Note:

I spent many years working with Jenkins and switch to GitLab CI 2 years ago. I've also used travis.

I like GitLab CI the most, here's a list of nice features:

• Bundled with GitLab (doh)
• Excellent documentation
• You can always deploy because your CI code lives next to your production code. In Jenkins, if you changed the job config without adding it to version control you're screwed
• gitlab-runner runs everywhere (macOS, Linux, Windows) and is very easy to configure/install (just a go executable and you're ready to go)
• Clean yaml based config
  • Jobs declaration with stages and environment name is awesome


• Supports Docker out of the box


• Integrated with Kubernetes


• Nice REST API

And here are a few things where Jenkins is better:

• Trying to figure out why your job is pending is not obvious and you have to be an admin to see all the running jobs.
• Every job starts with a completely clean git repo. You must use things like cache and artifacts to transfer files across jobs and pipelines. Sometimes I would just like a 'don't clean the git repo after checkout' option.
• If your gitlab-ci.yml go out of sync accross branches, things can get tricky...
• GitLab CI really insist on having one git repo per project: jobs across projects are hard to maintain.
• In the same vein, you cannot have 2 different jobs depending on which folder of the source code has changed.
• No plugins. You cannot for instance get a list of tests that passed with their history, for instance.

[Devin Handspiker-Wade]

You can have the "'don't clean the git repo after checkout' option". It's under "Git strategy" in runner settings. Doesn't really make a difference if you are using containers as they're disposed after a job completes but if you are using are SSH executor it doesn't clean the workspace.

[Dimitri Merejkowsky]

Wow I somehow missed that. Thanks !

[Kevin LaBranche]

Cake scripts that are then called verbatim via whatever tool I want. Script is sourced with project and calls to it are the same locally as with whatever CI/CD tool you choose. Keeps the "tool" exactly the same as the local setup and allows for easy migration to another tool (not that one would do that much).

[Cássio Dias]

concourse-ci.org/

[Pavan Belagatti]

Good option.

[rhymes]

Codeship because it's integrated with Heroku and easy to use :-)