Codeship vs GitLab CI vs TeamCity

Get Advice Icon

Need advice about which tool to choose?Ask the StackShare community!

Codeship
Codeship

938
615
+ 1
1.4K
GitLab CI
GitLab CI

908
545
+ 1
33
TeamCity
TeamCity

641
424
+ 1
267
- No public GitHub repository available -
- No public GitHub repository available -
- No public GitHub repository available -

What is Codeship?

Codeship runs your automated tests and configured deployment when you push to your repository. It takes care of managing and scaling the infrastructure so that you are able to test and release more frequently and get faster feedback for building the product your users need.

What is GitLab CI?

GitLab offers a continuous integration service. If you add a .gitlab-ci.yml file to the root directory of your repository, and configure your GitLab project to use a Runner, then each merge request or push triggers your CI pipeline.

What is TeamCity?

TeamCity is a user-friendly continuous integration (CI) server for professional developers, build engineers, and DevOps. It is trivial to setup and absolutely free for small teams and open source projects.
Get Advice Icon

Need advice about which tool to choose?Ask the StackShare community!

Why do developers choose Codeship?
Why do developers choose GitLab CI?
Why do developers choose TeamCity?

Sign up to add, upvote and see more prosMake informed product decisions

    Be the first to leave a con
    Jobs that mention Codeship, GitLab CI, and TeamCity as a desired skillset
    What companies use Codeship?
    What companies use GitLab CI?
    What companies use TeamCity?

    Sign up to get full access to all the companiesMake informed product decisions

    What tools integrate with Codeship?
    What tools integrate with GitLab CI?
    What tools integrate with TeamCity?

    Sign up to get full access to all the tool integrationsMake informed product decisions

    What are some alternatives to Codeship, GitLab CI, and TeamCity?
    CircleCI
    Continuous integration and delivery platform helps software teams rapidly release code with confidence by automating the build, test, and deploy process. Offers a modern software development platform that lets teams ramp.
    Semaphore
    Semaphore is the fastest continuous integration and delivery (CI/CD) platform on the market, powering the world’s best engineering teams.
    Jenkins
    In a nutshell Jenkins CI is the leading open-source continuous integration server. Built with Java, it provides over 300 plugins to support building and testing virtually any project.
    Shippable
    Shippable is a SaaS platform that lets you easily add Continuous Integration/Deployment to your Github and BitBucket repositories. It is lightweight, super simple to setup, and runs your builds and tests faster than any other service.
    Codefresh
    Automate and parallelize testing. Codefresh allows teams to spin up on-demand compositions to run unit and integration tests as part of the continuous integration process. Jenkins integration allows more complex pipelines.
    See all alternatives
    Decisions about Codeship, GitLab CI, and TeamCity
    GitHub
    GitHub
    Slack
    Slack
    Semaphore
    Semaphore
    Codeship
    Codeship

    When it comes to continuous Integration services, the choice is hard. There are several solutions available and it looks like the dev scene is very split. We've read and reviewed several solutions and we ended up making the choice between Codeship and Semaphore . Although Semaphore is used by slightly more developers, we've experienced a faster and easy flow using Codeship. Both do integrate Slack and GitHub very well, so this is not a point to set them apart. Both have a complex pricing system that is not that easy to calculate and predict. However, out in the wild, we found Codeship to have a better price point at heavy use.

    See more
    Tymoteusz Paul
    Tymoteusz Paul
    Devops guy at X20X Development LTD · | 13 upvotes · 257.3K views
    Amazon EC2
    Amazon EC2
    LXC
    LXC
    CircleCI
    CircleCI
    Docker
    Docker
    Git
    Git
    Vault
    Vault
    Apache Maven
    Apache Maven
    Slack
    Slack
    Jenkins
    Jenkins
    TeamCity
    TeamCity
    Logstash
    Logstash
    Kibana
    Kibana
    Elasticsearch
    Elasticsearch
    Ansible
    Ansible
    VirtualBox
    VirtualBox
    Vagrant
    Vagrant

    Often enough I have to explain my way of going about setting up a CI/CD pipeline with multiple deployment platforms. Since I am a bit tired of yapping the same every single time, I've decided to write it up and share with the world this way, and send people to read it instead ;). I will explain it on "live-example" of how the Rome got built, basing that current methodology exists only of readme.md and wishes of good luck (as it usually is ;)).

    It always starts with an app, whatever it may be and reading the readmes available while Vagrant and VirtualBox is installing and updating. Following that is the first hurdle to go over - convert all the instruction/scripts into Ansible playbook(s), and only stopping when doing a clear vagrant up or vagrant reload we will have a fully working environment. As our Vagrant environment is now functional, it's time to break it! This is the moment to look for how things can be done better (too rigid/too lose versioning? Sloppy environment setup?) and replace them with the right way to do stuff, one that won't bite us in the backside. This is the point, and the best opportunity, to upcycle the existing way of doing dev environment to produce a proper, production-grade product.

    I should probably digress here for a moment and explain why. I firmly believe that the way you deploy production is the same way you should deploy develop, shy of few debugging-friendly setting. This way you avoid the discrepancy between how production work vs how development works, which almost always causes major pains in the back of the neck, and with use of proper tools should mean no more work for the developers. That's why we start with Vagrant as developer boxes should be as easy as vagrant up, but the meat of our product lies in Ansible which will do meat of the work and can be applied to almost anything: AWS, bare metal, docker, LXC, in open net, behind vpn - you name it.

    We must also give proper consideration to monitoring and logging hoovering at this point. My generic answer here is to grab Elasticsearch, Kibana, and Logstash. While for different use cases there may be better solutions, this one is well battle-tested, performs reasonably and is very easy to scale both vertically (within some limits) and horizontally. Logstash rules are easy to write and are well supported in maintenance through Ansible, which as I've mentioned earlier, are at the very core of things, and creating triggers/reports and alerts based on Elastic and Kibana is generally a breeze, including some quite complex aggregations.

    If we are happy with the state of the Ansible it's time to move on and put all those roles and playbooks to work. Namely, we need something to manage our CI/CD pipelines. For me, the choice is obvious: TeamCity. It's modern, robust and unlike most of the light-weight alternatives, it's transparent. What I mean by that is that it doesn't tell you how to do things, doesn't limit your ways to deploy, or test, or package for that matter. Instead, it provides a developer-friendly and rich playground for your pipelines. You can do most the same with Jenkins, but it has a quite dated look and feel to it, while also missing some key functionality that must be brought in via plugins (like quality REST API which comes built-in with TeamCity). It also comes with all the common-handy plugins like Slack or Apache Maven integration.

    The exact flow between CI and CD varies too greatly from one application to another to describe, so I will outline a few rules that guide me in it: 1. Make build steps as small as possible. This way when something breaks, we know exactly where, without needing to dig and root around. 2. All security credentials besides development environment must be sources from individual Vault instances. Keys to those containers should exist only on the CI/CD box and accessible by a few people (the less the better). This is pretty self-explanatory, as anything besides dev may contain sensitive data and, at times, be public-facing. Because of that appropriate security must be present. TeamCity shines in this department with excellent secrets-management. 3. Every part of the build chain shall consume and produce artifacts. If it creates nothing, it likely shouldn't be its own build. This way if any issue shows up with any environment or version, all developer has to do it is grab appropriate artifacts to reproduce the issue locally. 4. Deployment builds should be directly tied to specific Git branches/tags. This enables much easier tracking of what caused an issue, including automated identifying and tagging the author (nothing like automated regression testing!).

    Speaking of deployments, I generally try to keep it simple but also with a close eye on the wallet. Because of that, I am more than happy with AWS or another cloud provider, but also constantly peeking at the loads and do we get the value of what we are paying for. Often enough the pattern of use is not constantly erratic, but rather has a firm baseline which could be migrated away from the cloud and into bare metal boxes. That is another part where this approach strongly triumphs over the common Docker and CircleCI setup, where you are very much tied in to use cloud providers and getting out is expensive. Here to embrace bare-metal hosting all you need is a help of some container-based self-hosting software, my personal preference is with Proxmox and LXC. Following that all you must write are ansible scripts to manage hardware of Proxmox, similar way as you do for Amazon EC2 (ansible supports both greatly) and you are good to go. One does not exclude another, quite the opposite, as they can live in great synergy and cut your costs dramatically (the heavier your base load, the bigger the savings) while providing production-grade resiliency.

    See more
    Joshua Dean Küpper
    Joshua Dean Küpper
    CEO at Scrayos UG (haftungsbeschränkt) · | 6 upvotes · 35.7K views
    atScrayos UG (haftungsbeschränkt)Scrayos UG (haftungsbeschränkt)
    Jenkins
    Jenkins
    GitLab Pages
    GitLab Pages
    GitLab
    GitLab
    GitLab CI
    GitLab CI

    We use GitLab CI because of the great native integration as a part of the GitLab framework and the linting-capabilities it offers. The visualization of complex pipelines and the embedding within the project overview made Gitlab CI even more convenient. We use it for all projects, all deployments and as a part of GitLab Pages.

    While we initially used the Shell-executor, we quickly switched to the Docker-executor and use it exclusively now.

    We formerly used Jenkins but preferred to handle everything within GitLab . Aside from the unification of our infrastructure another motivation was the "configuration-in-file"-approach, that Gitlab CI offered, while Jenkins support of this concept was very limited and users had to resort to using the webinterface. Since the file is included within the repository, it is also version controlled, which was a huge plus for us.

    See more
    Sebastian Dellwig
    Sebastian Dellwig
    Tech Lead at Porsche Digital GmbH · | 6 upvotes · 24K views
    Codeship
    Codeship
    CircleCI
    CircleCI
    GitLab CI
    GitLab CI

    We are using GitLab CI and were very happy with it. The integration of all tools like CI/CD, tickets, etc makes it very easy to stay on top of things. But be aware, Gitlab currently does not have iOS build support. So if you want to exchange that for CircleCI / Codeship to have to invest some effort. We are using a managed Mac OS device and installed the Gitlab runner there, to have iOS builds.

    See more
    Interest over time
    Reviews of Codeship, GitLab CI, and TeamCity
    Review ofCodeshipCodeship

    Working for a web agency, I have access to many premium services for all parts of the development process which leads to two things when it comes to working on my personal projects at home.

    1: I am more fussy about the quality of tools and services that I use than I was before I went from just messing around with programming to having a developer job.

    2: I really don't want to pay a single fee or any kind of subscription to services as after using them all day at work I find it hard to justify personally paying a premium to use them for a bit of time at home after work.

    However with Code ship neither of these things caused any issues as I found it to be very high quality and free.

    On the subject of it being free, I know there are other CI solutions that are free however if you wish to use it with a private repository then unless you already have private Github repos then the fact that Code Ship integrates with Bitbucket can be extremely convenient as it means you can set up your personal projects with free private repository and a free CI / testing solution for absolutely free.

    Overall Codeship has really impressed me in every way from its pricing to its clean and simple UI and its ease of use.

    Avatar of marcqualie
    Marc Qualie
    Review ofCodeshipCodeship

    Setting up continuous integration is complex and time consuming. I've used Codeship for 1 year now and I would never go back to previous systems such as self hosted Jenkins for any kind of web applications. The ability to change developer access on a per repository basis with the click of a button is very helpful and integration with all our services such as Github and Heroku make testing and deployment happen in the background so we can concentrate on our application and not worry about what state the live code is in. We also find the Slack integration (and flowdock before that) to be a great way to share the current code status with the whole team without getting spammed with emails on each commit and build state change while testing prototype branches or working on pull-requests.

    Review ofCodeshipCodeship

    Like most developers I'd love it if my deployment processes were always the same for every project so I never had to think about deployment. However, that's probably never going to happen unless we stop having clients. Codeship allows me to organize all of my deployments into one place and set them up once so that I don't have to remember the process for every nuance of every client.

    Whether it's deploying a Drupal or Wordpress site to a private server, a Meteor.js app to Modulus, or just about anything else Codeship gives me the flexibility of writing my own shell scripts for custom jobs (private server) but also one-click solutions for common problems (deployment to Modulus).

    Highly recommend them!

    Review ofCodeshipCodeship

    It's not easy to differentiate a CI/CD service because integrations matter so much more than the service itself. Didn't even need to read any docs, it just works exactly as you expect it to.

    Pros:

    • Pipelines for running tests in parallel (freemium).
    • Easiest setup of any CI service I've tried.
    • Mandatory build status image service.

    Cons:

    • Test runners are alright, but not that powerful. Py.test can run tests in parallel on its own, but enabling that feature doesn't seem to speed up Codeship runs.
    • Doesn't detect tox environments, so you have to specify one environment per pipeline manually.
    Avatar of gandhiShepard
    Ben Gandhi-Shepard
    Review ofCodeshipCodeship

    I spent half a day grepping CodeShip and now I have a sweet deployment process for WP sites. After a month of wrestling with Bamboo I decided to give CodeShip a try thanks to an article by CodeShip's Roman Kuba about deploying WP sites

    I am now killin' WP development with my CodeShip + WPEngine setup. This is also making WP development/deployment fun for the first time. CodeShip f*cking rocks.

    How developers use Codeship, GitLab CI, and TeamCity
    Avatar of DigitalPermits
    DigitalPermits uses TeamCityTeamCity

    TeamCity is our main continuous integration server. It starts creating builds and running tests based on commits that we make in our hosted bitbucket repositories. From there, we have a set of configuraitons that can deploy the built and tested artifacts (web app, batches, db, etc...) to a stage or production server. We still release manually, but we release often, and TeamCity has nice features to help us roll back when things don't work out as planned.

    Avatar of Stack Exchange
    Stack Exchange uses TeamCityTeamCity

    TeamCity builds then copies to each web tier via a powershell script. The steps for each server are:

    • Tell HAProxy to take the server out of rotation via a POST
    • Delay to let IIS finish current requests (~5 sec)
    • Stop the website (via the same PSSession for all the following)
    • Robocopy files
    • Start the website
    • Re-enable in HAProxy via another POST
    Avatar of Andrew Gatenby
    Andrew Gatenby uses CodeshipCodeship

    We use this as a CI tool when working on our API and related tools. The setup is relatively painless and it hooks directly into our Github repo's to provide reports and feedback.

    Avatar of RentChek
    RentChek uses CodeshipCodeship

    Runs a full test suite whenever we push changes to master and if everything is good, automatically deploys our changes to production.

    Avatar of Trusted Shops GmbH
    Trusted Shops GmbH uses GitLab CIGitLab CI

    We use Gitlab CI to unit and component test all of our application/components/modules. Therefore we use Docker runners.

    Avatar of Dynamictivity
    Dynamictivity uses GitLab CIGitLab CI

    GitLab CI is extremely flexible and easy to use. We also enjoy the elastic build infrastructure which is Docker based.

    Avatar of Sascha Manns
    Sascha Manns uses TeamCityTeamCity

    I'm using a selfhosted TC as Referenceplatform, and use travis with another configuration.

    Avatar of Kim Do Hyeon
    Kim Do Hyeon uses CodeshipCodeship

    원래 CircleCI 쓰다가 갑자기 슬랙으로 알림오는게 안돼서 Codeship 쓰는 중 Circle CI가 더 편함

    Avatar of Sanghyun Park
    Sanghyun Park uses GitLab CIGitLab CI

    Upon push, build the site and publish to Google Cloud Storage.

    Avatar of azawisza
    azawisza uses CodeshipCodeship

    build center and continous deployment for all services

    Avatar of Grubster
    Grubster uses CodeshipCodeship

    A QA tool that runs the platform's automated tests

    Avatar of Andrew King
    Andrew King uses TeamCityTeamCity

    Continuous integration for iOS apps.

    Avatar of cslasher
    cslasher uses GitLab CIGitLab CI

    CI/CD with Docker support.

    Avatar of Solcast
    Solcast uses GitLab CIGitLab CI

    Deployment pipeline

    Avatar of One Legal
    One Legal uses TeamCityTeamCity

    Build system.

    How much does Codeship cost?
    How much does GitLab CI cost?
    How much does TeamCity cost?
    News about GitLab CI
    More news