GitLab CI vs Snap CI: What are the differences?
Developers describe GitLab CI as "GitLab integrated CI to test, build and deploy your code". 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. On the other hand, Snap CI is detailed as "Build, test, and deploy software faster with Snap's continuous integration and deployment tool". Snap CI is a cloud-based continuous integration & continuous deployment tool with powerful deployment pipelines. Integrates seamlessly with GitHub and provides fast feedback so you can deploy with ease.
GitLab CI and Snap CI belong to "Continuous Integration" category of the tech stack.
"Robust CI with awesome Docker support" is the primary reason why developers consider GitLab CI over the competitors, whereas "Github integration" was stated as the key factor in picking Snap CI.
WebbyLab, Infoxchange, and Dial Once are some of the popular companies that use GitLab CI, whereas Snap CI is used by Hazeorid, Elerna, and Firecracker. GitLab CI has a broader approval, being mentioned in 210 company stacks & 93 developers stacks; compared to Snap CI, which is listed in 7 company stacks and 3 developer stacks.
What is GitLab CI?
What is Snap CI?
Need advice about which tool to choose?Ask the StackShare community!
Sign up to add, upvote and see more prosMake informed product decisions
What are the cons of using GitLab CI?
What are the cons of using Snap CI?
Sign up to get full access to all the companiesMake informed product decisions
Sign up to get full access to all the tool integrationsMake informed product decisions
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.
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.
We use Gitlab CI to unit and component test all of our application/components/modules. Therefore we use Docker runners.
GitLab CI is extremely flexible and easy to use. We also enjoy the elastic build infrastructure which is Docker based.