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

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.

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 :)

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.

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.

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)

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.

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.

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.

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).

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...

I've tried Travis and Circle CI (I preferred Circle CI because of the UI) Recently I've settled with Gitlab CI and i'm really loving it. It's easy to setup and has one of the features i wished Circle CI had which is manual deployments. A build might be successful but i might not want it to be deployed automatically. Hopefully Circle CI will have this option in the future. discuss.circleci.com/t/manually-tr...

I work at GitLab, so obviously GitLab CI :P

In the past for personal projects I've used Codeship or Circle CI, though now I use GitLab CI. For other open source projects I contribute to a lot use Travis, so I end up using that sometimes.

I won't shill too hard since I'm obviously biased, but I think GitLab CI with GitLab Pages is by far the best tool out there for static sites. GitHub Pages has a lot of limitations for deploying static sites, namely the lack of support for Jekyll extensions and the need to include everything in the repo.

With GitLab CI you can build the site dynamically, pulling from other repos or resources. We do this for the GitLab Documentation and it works great.

As for "normal" CI use-cases, it allows auto-scaling and parallelized builds for free (up to 2000 build minutes on GitLab.com for private projects, infinite for public projects). I'm a big fan of it.

Circle is probably the one I've used the most, as two different companies I worked for relied on it. There was a stretch of time when it was having some issues with one of our projects, but the real issue, it must be admitted, was that our integration tests were problematic, even when run locally, so Circle could not be blamed for that.

I've also used Travis and am now on a contract where we use Codeship. So far, at least, I haven't seen anything in particular that calls out one as significantly better than another. They all seem to do the job that needs doing, and they're all working out ways to do it with as little configuration as possible, which is a nice touch, while still allowing configuration where things get weird.

If I were choosing for a new project I suspect I'd go back to Circle simply because it's the one I know best right now, although I might choose Codeship for exactly the opposite reason -- it's the one I most want to learn (and am now starting to in my current contract).

We use Travis CI for our github-hosted open source game project, and for our website deployment.

Whn I worked at IMVU, we ran a heavily modified buildbot for continuous deployment. In later jobs, I've seen Jenkins used, but did not like it. There was a tendency for tests to take several minutes, which wasn't so much Jenkins' fault, but a result of developers not running tests on their own machines.

As far as advice goes: I don't think the tools are as important as it is to empower developers to run all tests on their own machines. When some step breaks on the build server, how are you going to debug what happened? For that reason also, prefer unit tests and dependency injection over complex integration tests whenever possible.

We're using Jenkins as CI server in our .NET project. Internal libraries are are built using MSBuild and are then packed into NuGet packages and deployed to our NuGet file share.
Our main application is also created via msbuild and pcked using nsis and an update manager that we programmed ourselves.
We enrich the build jobs with the ReSharper Suite, checking for findings and duplicate code as well as calculating the code coverage of our unit tests (dotCover).
For build monitoring we're using the BuildMonitor plugin for Jenkins and Catlight, which is a small tool that continuously checks the CI server for running/successful/failed jobs and notifies the developers in the windows task bar about changes.