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.
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 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.
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.
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.
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.
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 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...
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.
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.
Latest comments (28)
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.
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 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 developed badwolf for our BitBucket-hosted projects. github.com/bosondata/badwolf
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.
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!
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.
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.
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.