Top 5 IAST Tools for 2022
The trouble with allowing developers to deploy code directly to production is that security threats are often overlooked in the process. These vulnerabilities only show up
It is safe to say that most code in the world resides on either GitLab or GitHub. Which makes perfect sense in a cloud-based, OSS-dependent world. Without them, OSS and collaborative software development simply would not exist as they do today.
When it comes to selecting the code repository hosting platform for a new project there’s quite a bit to consider. Whether it be as part of a team or your pet projects. GitLab and GitHub are the first to come to mind (with BitBucket coming in third). But which is the right for your needs and the future of your software project?
If you were to choose purely based on general popularity, GitHub would be the clear winner, with over 56 million users and more than 190 million repositories (including at least 28 million public repositories).
But GitLab has its niche. According to the Snyk JVM Ecosystem report 2020, the leading repository among Java Developers was GitLab, with 35% of the surveyed developers picking it over others. This is quite a significant number, and means that GitLab supplies some very desirable features.
It is interesting to note that even though GitHub now offers free private repositories, it is not able to compete with GitLab quite yet. In a lot of people’s minds, GitLab is the place to go for private repositories and GitHub for the public ones. But does it have to be? Let’s find out.
Git is a Version Control system. The idea behind version control is that every time a change is made, a snapshot is taken of the entire codebase (sometimes including things that aren’t code). This allows, at the very core, the option to go back to earlier versions of the code in case something broke.
Going back in time is far from the only feature of version control, though. Having control of what gets put into the code is critical. It becomes even more vital for public open-source projects, which could not exist without Git.
Git has been the leading version control system for quite some time now, overtaking SVN around 2018. Part of the reason is the preference of developers for Git as a versioning system with the main driver being local commits.
Unlike SVN, which only allows committing code to the main repository, Git allows developers to commit code to their local checked-out code. This is a significant improvement over SVN’s system which allows developing large code features locally to completion before merging it to the main repository. In SVN the agreed-upon method for achieving something similar would be to create a branch in the main repository, which can quickly cause branch bloat and become a nightmare to manage.
However, the main drive for Git Adoption is the free and accessible nature of hosting code repositories on platforms like GitHub and GitLab. Open-source code as it exists today would likely not be feasible without a free platform to host it on. Having to pay hard-earned cash to host open-source code would be a major barrier for the open-source community. Most people are happy to invest their time and knowledge into a project they are passionate about, but ask them to spend money and a large number of them would walk away.
GitHub is a repository hosting platform, offering everything a developer might need in terms of issue tracking and code management in one convenient free package. GitHub is so popular that it has become almost a synonym with Git.
The vast majority of open-source code repositories are hosted on GitHub. This is not surprising given it was the only such platform at the time of its conception. To this day, not many alternatives provide the same robust core features for free.
GitHub was founded in 2008 as an online code repository by Chris Wanstrath, P. J. Hyett, Tom Preston-Werner, and Scott Chacon using Ruby on Rails. The platform saw an immediate surge in uptake, hitting a staggering 46,000 hosted repositories within the first year and double that by the end of the second year.
GitHub was acquired by Microsoft in 2018 which led to a number of changes. The most important of these were free private repositories without limitations and CI/CD integration. CI/CD integrations were only added to GitHub in late 2019, but it has been possible to use Jenkins with your GitHub repositories for a long time.
GitLab, unlike GitHub, was developed as a collaboration tool rather than a repository hosting solution. Dmitriy Zaporozhets started the project under an open-source license as he felt a good collaborative tool was missing. CI/CD has always been at the core of GitLab, being a collaborative tool first and a repository second.
Current CEO, Sid Sijbrandij, saw the project in 2012 and was impressed by the quality of code. He then founded GitLab inc, and hired Dmitriy Zaporozhets to work in the company so he could focus on GitLab full time.
GitLab’s core product remained open source as it gained popularity, splitting into two code bases. The community edition was aimed at individuals and open source projects. And the Enterprise Edition, which was aimed to provide companies the tools they needed.
In 2014, GitLab Inc. announced an open-core business model, keeping the code open source but offering additional features and services to paying customers. Under this new business model, it made sense to keep the Community features completely free and open-source while the Enterprise Edition moved to a more limited license. Although Enterprise Edition remained public-facing, and all changes to the code could be viewed.
When having to choose between two platforms, the differences between them are going to be the driving force of the decision. It’s important to know from the start what you are going to get from one platform or another so you can make an informed decision.
GitHub has only recently added GitHub Actions in late 2019, probably largely in response to GitLab’s growing market share. The question is, now that it is out, how does it compare to GitLab?
GitLab’s website has a full page dedicated to the shortcomings of GitHub Actions compared to their infrastructure. This may be a somewhat biased list, and would probably discard any advantages GitHub has over GitLab, it is still a pretty exhaustive list of differences.
One of the major advantages of GitLab is that it has an integrated CI tool that requires little to no setup to get started with. That means that if you have limited experience with CI/CD pipelines, GitLab could be your portal into this world of efficient code testing and continuous delivery.
That said, according to JVM Ecosystem report 2020, the vast majority of DevOps still use Jenkins, even if they are using GitLab for the repository.
GitHub doesn’t fall short of GitLab when it comes to Jenkins integration. So if you are intending to use Jenkins, GitLab’s integrated CI tool is probably not an appeal.
GitHub is much older than GitLab, which means a lot of users that are using the platform for a long time and are very proficient with it. It also means general familiarity with the platform is widespread. It is not that GitLab is challenging to use, but when it comes to community, size matters.
Feel free to see this as anecdotal evidence, but in my personal experience, more communities use GitHub. To this day I have been pointed to countless GitHub repositories from all sorts of projects, whether it be for issue reporting, readme or installations. Not once have I been linked to a public GitLab repository.
This doesn’t mean it won’t change in the future, but as it stands today, the GitHub community, and particularly the open-source community, is magnitudes larger.
It is hard to compare the pricing between GitLab and GitHub because the paid features are vastly dissimilar. The pricing structure for the two platforms is quite different as well. The main feature that scales for GitLab is CI/CD minutes, while GitHub scales both Actions and Storage space with the user plan. For increased Storage on GitLab, you’d pay separately.
Free – 400 CI/CD Minutes
$21/User/Month – 1,000 CI/CD Minutes.
$99/User/Month – 50,000 CI/CD Minutes.
$10 one-time payment – 1000 additional CI/CD Minutes
$60 annual – 10GB Storage. (first 10 GB are free)
Free – 500MB and 2000 Actions Minutes.
$4/User/Month – 2GB and 3000 Actions Minutes.
$21/User/Month – 50GB and 50,000 Actions Minutes.
GitHub One is also available, but there is no public pricing and will depend on negotiation with the sales team.
At face value, GitLab is quite significantly more expensive in terms of Storage and CI/CD minutes. GitLab does however advertise priority support starting at the $19 price level, while GitHub only advertises 24/7 support at the GitHub One level, price unknown.
GitHub and GitLab have many overlapping features, but some of them have minor differences worth noting. These differences are not likely to sway you one way or the other on their own, but you should take them into consideration when the choice is close. And with the two platforms in question that is very likely to happen.
Feature | GitLab | GitHub |
Analytics – Allows a deep look into your development cycle. Quick cycles are a boon, and this tool will help you find your bottlenecks. | Value Stream analytics is free, and there are more analytics features available from the $19 version onward. | GitHub Insights is only available for GitHub One. |
Open Source – An open-source code allows for failsafe. Allowing you to install the platform on a private server. | GitLab is an open-core business and stands on the shoulders of a robust open-source platform. | GitHub is close-core, which means you cannot choose to move your projects to a private server. |
Issue Tracking – An important feature for collaboration. | GitLab offers a more complex and feature-rich issue tracking at the cost of being less friendly and easy to use. | GitHub has a simple and elegant issue tracking platform that non-developers will have no issue approaching. |
Export/Import – Being able to move an existing code base to the platform, or away from it is important for future-proofing. | GitLab is the leader in allowing easy import and export with extensive documentation on how to import projects. | GitHub does cover this ground with GitHub Importer, but it is not as straightforward a user experience. |
While moving your project from one to the other is very feasible, it’s never a good experience having to move platforms. Making the right choice at the right point in time can save you many work hours.
The feature that pulls the most people to GitLab is undoubtedly the integrated CI/CD tools. While GitHub has those too, GitLab has a lot more experience under its belt in this regard. If integrated CI/CD tools are a major appeal then GitLab is the right choice.
Being open source is the second major appeal to GitLab. Having the community being a driving force in pushing the platform forward is sure to bring innovation to the platform. That, along with being able to run a private installation on a server you own are good reasons to pick GitLab.
GitHub has been around for over a decade and is an established platform. Being a known quantity in the world of open-source means that if you intend to run an open-core or open-source project, contributors will be knowledgeable in how it works.
Cheaper CI/CD minutes is something to consider, along with the automatic expansion of storage with users. At $21 a month, GitHub users get as close to a limitless supply of CI/CD minutes as a company could give for that price. And it also comes with 50GB of storage. This price point would be very appealing for many.
GitHub has been the leading horse for a long time, but GitLab is catching up with some powerful features. In this post we’ve gone over a bit of history, the major and minor differences between the two, and the pivotal features that may make you choose one over the other.
There are clear advantages to both, but whether you go with the well Established GitHub or the emerging GitLab, you’re getting a platform that has most, if not all, of your needs, covered. Albeit possibly to different degrees and at different price points.
The trouble with allowing developers to deploy code directly to production is that security threats are often overlooked in the process. These vulnerabilities only show up
In 2022, the adoption of infrastructure as code (IaC) soared, with IaC domain specific languages like HCL, Shell and GoLang gaining popularity and momentum across the
If you use the Azure cloud, Azure security groups should be on your radar because they’re a fundamental component of securing your resources. As we move