What tools do you use for CI/CD? Past experiences, recommendations?

Comments

[Adrian Kirsten]

In our office we don't have such a big need for the "bigness" of CI tools but do use a CD service called buddy.works/. We run their standalone version, and it's bloody awesome.

I get that it won't be as advanced as you guys want/need, but for smaller projects / teams / companies it's awesome.

I guess in time we will migrate over to something more powerful, but right now it's more than suitable.

[Buddy]

Hey Adrian, thanks for putting Buddy on the list! Do not be deceived by our simple GUI: I can assure you we have everything to handle even the most advanced projects with over 30 Docker-based actions – from builds and tests to deployments to devops to website monitoring.

And for those who prefer configuration as code we have full YAML support: buddy.works/knowledge/yaml/yaml-in...

Just our two cents to make things clear, thanks for your kind words on Buddy!

[Ondřej Mirtes]

I'm currently a CI/CD junkie 🤓 We use TeamCity and we've invested a lot in tools that check as most defects as possible in our code automatically. Our stack consists of PHP and other technologies and I've written an article aptly called "The Three Pillars of Static Analysis in PHP": medium.com/@ondrejmirtes/three-pil... We check the code automatically for syntax errors, formatting errors, stuff like unused imports and properties.

And I've created a tool for advanced static analysis with the aim of finding bugs. Since PHP is a dynamic language, it's been quite a challenge and it's not possible to check everything, but a lot of stuff can be caught in CI before reaching production :) It's called PHPStan: github.com/phpstan/phpstan It's my biggest side project yet and I'm really excited about it :)

[Corentin H. ⚡]

I configured GitLab CI in my company. I'm not a sysadmin or anything, just a dev so I used the most practical tool, as I has already set up GitLab as our private versioning system (to replace BitBucket) a few months before, with included issues handling.
Other than that, most of our repos are Docker based, so pretty easy to deploy with any CI, I guess.

[Petar G. Petrov]

CruiseControl in the past. Atlassian Bamboo currently. I'd say Bamboo is really a great tool. You need to do a considerable amount of configurations first, but after that it just works great. You can even build on remote servers, i.e., Windows machines, and it collects the output back to the local build project. You can easily install plugins, i.e., Gradle, extensive JUnit parsing & reporting, etc. You have full control on what and how to be build, i.e., Git branches with certain prefixes, etc.

Downsides - configuration is a bit quirky and it costs money.

[Yury]

I wish they had project level permissions. It's a really good tool and integration with JIRA and other Atlassian tools is the reason why we use it, but it sucks when you have to ask administrators to create a new plan because you want to try something

[Yury]

We use 5.13.2. Atlassian didn't mention it in release notes and the ticket for project permissions in their JIRA is still open, so I don't think they did it in 5.14. Well, they have more important issues and I haven't run into any CI tool which doesn't have permission issues when you try to share your CI instance across all teams

[Scott Hague]

Currently using a the GitLab integrated CI engine after making the move from some of the other hosted CI platforms out there. Our CI runs on all push requests and then deals with the entire pipeline of testing, packaging and deploying our staging/UAT/production apps. We are currently running this all off docker and deploying into our private cloud via ssh. Once I got my head around the initial config it's very easy to use and supports all of the platforms and languages we use internally (Go,nodejs,PHP)

[David J Eddy]

CI/D junky here as well. In the current employment setting we use JIRA issue management, using ticket numbers for branches in Bitbucket, development via PHPStorm with UpSource available for reviews in between merge request. Once a feature has been 'completed' by the developer and a pish is made to bitbucket our jenkins pulls the branch and executes the testing suits. Under the assumption the tests pass and the branch is of the defined name the application is deployed to a UAT/Staging environment.

Once all stakeholders have approved the changes we merge the devel branch into master (triggering the test/build process again) and deployed to the production environment.

Minus the approval process everything is automated from push to deployment.

[Omer van Kloeten]

I recently had to choose a CI tool for our multi-tech-stack project. I looked at Travis, Circle, TeamCity and Jenkins and ended up going for Jenkins because the first two were not powerful enough and I had past experience with Jenkins.

It's pretty bad. I mean I want to write CI-as-Code and Jenkins lets me do that (with Jenkinsfiles), but the scripting is in Groovy, there are few to no developer tools, documentation is near non-existent and when it is, it's usually outdated, there are five ways to do what you want, but only one of them actually works, and some tech stacks are just not supported at all (so yay bash scripting).

I've been working on it for about a week. It looks like I got it to work, but I'm super unhappy about how it's turning out.

[Alexey Zimarev]

We have Atlassian stack so tried Bamboo and stayed. The build process configurator is powerful but we barely use it due to the fact the we build using FAKE scripts (.NET people). However we also build Android and iOS apps using remote agents. In general, artefacts, chain builds and so on is done well although I am avoiding it.

I like the branch build feature very much since I do not like to see separate build plans for the same project just because I have branches. Bamboo can also create new build plan branches automatically if there is a new published branch, check the merge and remove the branch plan when the branch is removed (conditions can be customised).

For the CD we use Octopus Deploy. I personally find it too complex since it has many ways to do the same thing and this usually leads to confusion. But it works. In some plans we combined it with Bamboo deployment plans (Bamboo just triggers the deployment on Octopus) and by this you can see the deployment status/environment back in JIRA.

In general I find using proper build scripts is important and I like FAKE, people can build locally before pushing changes and eventually finding that the build does not work because of something.

[Jilles van Gurp]

Docker is the tool of choice for us these days. We started dockerizing our apps a few years ago. But then we realized it provides a great solution for solving the mess of dependencies that used to be our jenkins CI server. We had a crap load of node.js, python and other crap in, typically, not quite up to date and flaky setups on our jenkins. All of that got dockerized. Including jenkins itself.

All our builds now consist of calling docker build on the relevant repo, publishing the resulting docker image with the right tags (branch) and name, and then deploying the resulting image to a staging/production (depending on the branch) using scripts that are part of another docker image that we docker build every time scripts get modified in our deployment repo. The only thing we have on our jenkins server (besides jenkins) is docker and a few generic scripts for triggering the above.

Several big advantages: 1) All our apps include Dockerfiles that document exactly what is needed to build and how to run them. Any configuration is injected via environment variables, as is the Docker way. Our CI builds are simple calls to docker build and essentially the same script for all our apps. This is way better than any README, which lets face it are always incomplete and out of date or having a lot of convoluted and undocumented stuff going on in CI builds. 2) Anyone in our team can run any of our apps straight from the docker repo as long as they have docker installed on their laptop. 3) We can spin up test environments with docker compose easily both for development and CI. 4) Docker's notion of layering containers is great when your build includes a "download the world" step because it can be cached. This makes repeat builds fast when they can be. Whether you are doing maven, npm, or bundler, that's a good thing and it gets rid of cruft accumulating on your build servers. 5) Docker imposes a clean separation between dev responsibility and ops responsibility. Devs provide working docker containers with all their dependencies included. Ops provide infrastructure that can run the images + nw infrastructure & config in the form of env variables to wire everything together.

All of our deploys (testing and production) are triggered by commits or pull requests). Our production deploy process is: approve the pull request from master to our production branch. ETA, about 10 minutes after doing that. Any master commits automatically roll out to our staging. We can spin up development branch specific environments easily as well and achieve the same automation (a dev branch without CI is the same as not doing CI; i.e. don't do that).

[Alexis Tacnet]

I'm currently using DroneCI with Docker on my private server : the build, push and integration are done by drone and a docker registry. I use it for every project : Python, Web, Go, etc. ...

So I use drone to get the code, compile it, build a Docker image with the output of compilation and push it to a Docker registry. Then Drone SSH on my machine, pull the image and update the container.

It is very simple to use and I love to have container Runners to run my code, I prefer it to VM because it seems more adapted (you destroy it just after, like a container is meant to).

I've wrote an article on it if you want to know more : kodewolf.com/blog/continuous-integ...