Need advice about which tool to choose?Ask the StackShare community!
Concourse vs GitLab CI: What are the differences?
Differences between Concourse and GitLab CI
Concourse and GitLab CI are two popular continuous integration and delivery platforms, each offering their unique features and capabilities. Here are the key differences between Concourse and GitLab CI:
Architecture: Concourse is based on a distributed architecture where each part of the pipeline runs in containers, allowing for better scalability and isolation. On the other hand, GitLab CI follows a monolithic architecture with all the components tightly integrated within a single application.
Resource Model: Concourse has a unique resource model where resources are treated as first-class citizens and are defined in separate files. These resources are responsible for triggering builds when changes occur. In contrast, GitLab CI relies on repositories as the primary trigger for pipelines.
Pipeline Configuration: In Concourse, pipeline configuration is defined using a declarative YAML syntax, allowing for more explicit and fine-grained control over the pipeline definition. GitLab CI, on the other hand, uses a GitLab-specific YAML syntax, which may be more familiar for GitLab users but may lack some of the flexibility and expressiveness of Concourse's syntax.
User Interface: Concourse emphasizes a minimalistic and text-based user interface, focusing on the representation of pipeline resources and their states. GitLab CI, on the other hand, provides a more comprehensive web-based user interface, offering a wide range of features beyond just CI/CD, such as project management, issue tracking, and more.
Integration with GitLab: GitLab CI is tightly integrated with GitLab, allowing for seamless integration with other GitLab features like code repositories, issue tracking, and merge requests. Concourse, on the other hand, is a standalone tool that can integrate with various source control systems, including GitLab, but lacks the deep integration and native support that GitLab CI offers.
Extensibility: Concourse offers a flexible plugin system that allows users to extend its functionality by creating custom resource types and custom tasks. GitLab CI, on the other hand, offers limited extensibility options and relies more on the built-in features provided by the platform.
In summary, Concourse and GitLab CI differ in their architectural approach, resource model, pipeline configuration syntax, user interface, integration with GitLab, and extensibility options. Choosing between the two depends on specific requirements, preferences, and the existing ecosystem of tools and infrastructure.
I'm planning to setup complete CD-CD setup for spark and python application which we are going to deploy in aws lambda and EMR Cluster. Which tool would be best one to choose. Since my company is trying to adopt to concourse i would like to understand what are the lack of capabilities concourse have . Thanks in advance !
I would definetly recommend Concourse to you, as it is one of the most advanced modern methods of making CI/CD while Jenkins is an old monolithic dinosaur. Concourse itself is cloudnative and containerbased which helps you to build simple, high-performance and scalable CI/CD pipelines. In my opinion, the only lack of skills you have with Concourse is your own knowledge of how to build pipelines and automate things. Technincally there is no lack, i would even say you can extend it way more easily. But as a Con it is more easy to interact with Jenkins if you are only used to UIs. Concourse needs someone which is capable of using CLIs.
We are a mid-size startup running Scala apps. Moving from Jenkins/EC2 to Spinnaker/EKS and looking for a tool to cover our CI/CD needs. Our code lives on GitHub, artifacts in nexus, images in ECR.
Drone is out, GitHub actions are being considered along with Circle CI and GitLab CI.
We primarily need:
- Fast SBT builds (caching)
- Low maintenance overhead (ideally serverless)
- Everything as code
- Ease of use
I think I've tried most of the CI tools out there at some point. It took me a while to get around to Buildkite because at first I didn't see much point given it seemed like you had to run the agent yourself. Eventually it dawned on me why this approach was more ingenious than I realised:
Running my app in a production (or production-like) environment was already a solved problem, because everything was already in some form of "everything as code". Having a test environment where the only difference was adding the Buildkite agent was a trivial addition.
It means that dev/test/prod parity is simple to achieve and maintain. It's also proven to be much easier to support than trying to deal with the problems that come with trying to force an app to fit into the nuances and constraints that are imposed by the containers/runtime of a CI service. When you completely control all of the environment the tests are running in you define those constraints too. It's been a great balance between a managed service and the flexibility of running it yourself.
And while none of my needs have hit the scale of Shopify (I saw one of their engineers speak about it at a conference once, I can't find the video now though 😞) it's good to know I can scale out my worker nodes to hundreds of thousands of workers to reduce the time it takes for my tests to run.
I would recommend you to consider the JFrog Platform that includes JFrog Pipelines - it will allow you to manage the full artifact life cycle for your sbt, docker and other technologies, and automate all of your CI and CD using cloud native declarative yaml pipelines. Will integrate smoothly with all your other toolset.
more configurable to setup ci/cd: * It can provide caching when build sbt, just add this section to yml file * Easy to use, many documentation
Weakness: * Need use gitlab as repository to bring more powerful configuration
Buddy is one of the most easy-to-use tools for CI I ever met. When I needed to set up the pipeline I was really impressed with how easy it is to create it with Buddy with only a few moments. It's literally like: 1. Add repo 2. Click - Click - Click 3. You're done and your app is on prod :D The top feature that I've found is a simple integration with different notification channels - not only Slack (which is the one by default), but Telegram and Discord. The support is also neat - guys respond pretty quickly on even a small issue.
Pros of Concourse
- Real pipelines16
- Containerised builds10
- Flexible engine9
- Fast6
- Open source4
- No Snowflakes3
- Simple configuration management3
- You have to do everything2
- Fancy Visualization1
Pros of GitLab CI
- Robust CI with awesome Docker support22
- Simple configuration13
- All in one solution9
- Source Control and CI in one place7
- Integrated with VCS on commit5
- Free and open source5
- Easy to configure own build server i.e. GitLab-Runner5
- Hosted internally2
- Built-in Docker Registry1
- Built-in support of Review Apps1
- Pipeline could be started manually1
- Enable or disable pipeline by using env variables1
- Gitlab templates could be shared across logical group1
- Easy to setup the dedicated runner to particular job1
- Built-in support of Kubernetes1
Sign up to add or upvote prosMake informed product decisions
Cons of Concourse
- Fail forward instead of rollback pattern2
Cons of GitLab CI
- Works best with GitLab repositories2
