Dimensional Data

GitLab is focused on helping developers iterate faster and innovate more collaboratively – and that focus on enabling iteration extends to our own developer culture. As an organization, our CREDIT values are hardwired into our operations and culture. This empowers our development teams to work together – using our own product – to offer QA, feedback, and strategies that make everyone’s work stronger and help our organization iterate faster. We asked several engineers and engineering leaders at GitLab to tell us, in their own words, how our values come to life in our engineering organization and how that makes GitLab a unique place to be a developer. What attracts engineers to GitLab To start, we wanted to understand what attracted some of our current engineers and engineering leaders to join GitLab. You’re invited! Join us on June 23rd for the GitLab 15 launch event with DevOps guru Gene Kim and several GitLab leaders. They’ll show you what they see for the future of DevOps and The One DevOps Platform. “I was attracted to GitLab because I knew that I had the ability to make an impact. Being remote has shattered the walls between people and teams, so anybody can approach anybody. If something means something to you, you can really work on it. This culture of transparency and collaboration is really important to me.” – Sri Rangan, Fullstack Engineer, Incubation Engineering Team “People are attracted to the global diversity of the team and working asynchronously. I think we have a special working culture at GitLab. When you join, whether you’re the manager of multiple people or a manager of yourself, you work asynchronously regardless of where your teams are.” – Mek Stritti, VP, Quality “Before coming to GitLab, I was a frontend, backend, Android developer, data scientist, and machine learning engineer, among other things. But the thing about how I work is that I like to switch between those roles. And normally in companies, you can’t grow across all those roles. You need to grow as a specialist, not a generalist. But within the Incubation Engineering team, I get to do that.” – Eduardo Bonet, Fullstack Engineer, Incubation Engineering Team “The feedback that I quite often hear from engineers is just how strong the team is around them, and how collaborative the rest of the organization is. For my team in particular, a big part of their success is to be able to collaborate effectively with both the people that they work with and other teams. A lot of candidates are attracted to GitLab by the transparency value. Transparency is something that we really try to encourage, and it becomes a big mindset.” – Bartek Marnane, VP, Incubation Engineering How we ensure collaboration across the organization Beyond the aspects of GitLab that attracted many of our current engineers, it was clear that the culture they experienced during their time here ensured there was collaboration across various teams within our engineering organization. “We have an organization that supports each other. You propose a feature, you’re building something, and you can collaborate very easily across the globe, across departments with people in infrastructure and security. So when you’re building something it’s not all on you to ensure its stability and reliability and safety – the entire organization takes ownership of that.” – […]

In this day and age, organizations need to deliver innovative solutions faster than ever to their customers to stay competitive. This is why solutions that speed up software development and delivery, such as Quarkus and GitLab, are being adopted by teams across the world. Quarkus, also known as the Supersonic Subatomic Java, is an open source Kubernetes-native Java stack tailored for OpenJDK HotSpot and GraalVM, crafted from respected Java libraries and standards. Quarkus has been steadily growing in popularity and use because of the benefits that it delivers: cost savings, faster time to market/value, and reliability. Quarkus offers two modes: Java and native. Its Java mode builds your application using the JDK and its native mode compiles your Java code into a native executable. GitLab, the One DevOps Platform, includes capabilities for all DevOps stages, from planning to production, all with a single model and user interface to help you ship secure code faster to any cloud and drive business results. Besides DevOps support, GitLab also offers GitOps support. The combination of Quarkus and GitLab can empower your developers and operations teams to collaborate better, spend more time innovating to deliver business value and differentiating capabilities to end users. In this article, we show how to automate the software delivery of a generated Quarkus application in Java mode using GitLab Auto DevOps. Below we list the steps how to accomplish this. Prerequisite The prerequisite for the subsequent instructions is to have a K8s cluster up and running and associated to a group in your GitLab account. For an example on how to do this, please watch this video. Generate your Quarkus project using the generator and upload to GitLab From a browser window, point to the Quarkus generator site, https://code.quarkus.io, and click on the button Generate your application. Generate a sample Quarkus application using the generator On the popup window, click on the button DOWNLOAD THE ZIP, to download a sample Quarkus application in a ZIP file to your local machine. The downloaded file is named code-with-quarkus.zip. Unzip the file on your local machine in a directory of your choice. This will create a new directory called code-with-quarkus with all the files for the sample Quarkus application. From a browser window, open https://gitlab.com, and log in using your GitLab credentials. Head over to the GitLab group to which you associated your K8s cluster and create a blank project named code-with-quarkus. Create project code-with-quarkus From a Terminal window on your local machine, change directory to the newly unzipped directory code-with-quarkus and execute the command rm .dockerignore to delete the .dockerignore file that came with the sample Quarkus application. After removing this file, execute the following commands to populate your newly create Git project code-with-quarkus with the contents of this directory: NOTE: Depending on your version of git installed on your local machine, the commands below may vary. Keep in mind that the goal of the steps below is to upload the project on your local machine to your newly created GitLab project. git init git remote add origin https://gitlab.com/[REPLACE WITH PATH TO YOUR GROUP]/code-with-quarkus.git git add . git commit -m “Initial commit” git push –set-upstream origin master At this point, you should have your sample Quarkus application in your GitLab project code-with-quarkus. Modify the generated Dockerfile.jvm file and indicate its location […]

A little over a year ago, GitLab acquired UnReview, a machine learning-based solution for automatically identifying appropriate relevant code reviewers and distributing review workloads and knowledge. Our goal is to integrate UnReview’s ML-powered code review features throughout GitLab, the One DevOps Platform. We checked in with Taylor McCaslin, principal product manager, ModelOps, at GitLab, to find out the impact UnReview has had so far and what comes next. The idea of applying machine learning to code review was already underway at GitLab before the UnReview acquisition. What was it about ML/AI and automation that seemed a good fit for the code review process? How did the UnReview acquisition affect that strategy? The acquisition of UnReview gave GitLab a practical way to get started with a really focused value proposition that was obvious to the platform. ML/AI is a lot more than just having a useful algorithm. UnReview and its team gave GitLab talent with experience building MLOps pipelines and working with production DataOps workflows. As a source code management (SCM) and continuous integration (CI) platform, MLOps and DataOps are key ambitions for our ModelOps stage. UnReview is the foundational anchor of our Applied ML group, and we anticipate developing more ML-powered features with the base that we’ve built integrating UnReview into our One DevOps platform. If it’s something you manually set today within GitLab, we’ll consider suggestions and automations: suggested labels, assignees, issue relationships, etc. You can learn more about our plans on our Applied ML direction page. You’re invited! Join us on June 23rd for the GitLab 15 launch event with DevOps guru Gene Kim and several GitLab leaders. They’ll show you what they see for the future of DevOps and The One DevOps Platform. There were three specific objectives with the UnReview project when you first started: Eliminate the time wasted manually searching for an appropriate code reviewer to review code changes. Make optimum recommendations that consider the reviewers’ experience and optimize the review load across the team, which additionally facilitates knowledge sharing. Provide analytics on the state of code review in the project, explaining why a particular code reviewer is recommended. Have you had to change or add to these in any way? We now have Suggested Reviewers running for external beta customers as well as dogfooding it internally. We’ve learned a lot about what makes a good code reviewer. Some of the obvious things like context with the changed files and history of committing to that area of code are obvious. But there are less obvious things like what type of code someone has experience with (front-end or back-end). We’re finding the concept of recency interesting: the idea that people who more recently interacted with files and functions may be better suited to review the code. Also, people leave companies, and that’s usually not something that can be inferred by the source graph, so we’re working on merging additional GitLab activity data with the recommendation engine. In addition, we’re thinking a lot about bias in our recommendations. For example, a senior engineer likely has the most commits across a project, but we don’t always want to recommend a senior engineer. The more we work with the algorithm and recommendations, the more nuanced we find it. Not every organization does code review the same way, so we’re […]

Association Française pour le Nommage Internet en Coopération (Afnic) is a longstanding nonprofit in France that manages .fr domain names. Chosen 20 years ago by the French State to operate the .fr country code top-level domain, Afnic’s motto is “reliability first.” Afnic uses GitLab, The One DevOps Platform, to help sustain that motto through modernization of its software development environment. Afnic’s mission as the French National Top Level Domain Registry is to bring together public authorities, Internet users, and domain name professionals to build a secure and stable Internet, open to innovation and in which the French Internet community plays a leading role. Outages of such a digital service could prevent the provisioning of other services that rely on it and could thus have an impact on key economic and societal activities. Afnic started using GitLab about four years ago to build and secure the brand-new version of its Shared Registry System (SRS). The SRS is a platform that manages the domain names from the subscription of a domain name to the publication in the DNS database and all the updates during its life, including contacts, server names, and DNSSEC keys, according to Richard Coffre, Afnic’s principal product manager. Since the project began, all the technologies have changed. Previously, Afnic’s team was mainly using Java and Perl and now they use Kubernetes, Angular, the latest version of Java, and Docker, among others. Security is paramount, and the team is using private clouds. That means Afnic has its own data centers in France and in colocation facilities all over the world. Modernizing software development with automation and integration Afnic selected GitLab to automate and integrate processes during the deployment process. Previously, the majority of things were done manually and now Afnic’s team wants to follow DevSecOps philosophy and governance. They wanted one DevOps platform with state-of-the-art CI/CD capabilities, the ability to quickly onboard new developers, and features to improve compliance and monitoring functionality. Now, Gitlab is one of the core components of Afnic’s systems. The company’s use of GitLab expanded as they deployed new versions of Java and Docker and other technologies. “We wanted to take a big step to align our technology with the state of the market,” Coffre says, and after surveying the development team, the choice was GitLab. The team is integrating GitLab with Jira, which is providing a lot of value, he adds. Now, in addition to developers, Afnic’s database administrators and network administrators use GitLab. The team is using Docker for images and Ansible. Jira is used for ticketing issues and is linked to GitLab and Confluence as a wiki to create the documentation. What GitLab brings to the table The goal for Afnic is to increase automation and to have everything in the same place and for anyone to be able to get at the proper version anytime. “That’s the strength of GitLab,” Coffre says. “That’s also why we chose it because it’s one of the leaders. Like many modern source code management systems, GitLab allows our developers to concurrently create source code. But it does it easily, giving us the possibility to do it safely, remembering our motto.” Previously Afnic used only open source tools that they had to customize, which Coffre says was not efficient on a daily basis. To manage source code […]

Blonk is an international leader in the field of environmental and sustainability research in the agri-food sector. But as a small business without a QA team or a security team, the challenge was figuring out how to deliver professional software with only a few developers. Blonk used an external company to help set up what Bart Durlinger, product development manager, and software devevloper Pieter van de Vijver envisioned as its platform at the time. “They set up an environment on Amazon, a separate built server, a separate repository, and then some scripts in between to link it all together,” Durlinger recalls. “But when we decided to take more control, that was just too complex. We had too many different parts in many different places. We didn’t have the capacity at the time to really oversee how this should all work together.” That’s when the Blonk team started looking for platforms that offered a more integrated approach, with project management, CI/CD, repository, and version control features all in one place. Mature, with a modern vision of software development Blonk turned to GitLab after finding that the platform “had a lot of the things you need to have a professional delivery pipeline integrated into one solution,” says Durlinger. At the time, the consultancy was using GitHub, which was more expensive, he says. When Blonk started with GitLab, the platform was free, which was a big factor in its selection, van de Vijver says. “But it was also an up-and-coming startup with a vision of that CI/CD integration built into how you envisioned the whole service itself,” he says. “GitHub was more of a repository that might provide you with those things, but it required more manual setup.” Blonk liked that GitLab was a mature and stable solution “but still new enough to have a vision of how software is approached nowadays with easy setup and an integrated pipeline by default, and useful branching strategies by which you could support a multi-level, multi-stage deployment process easily,” Van de Vijver says. At the time Van de Vijver was the only one at Blonk with a background as a software developer, and another bonus was his familiarity with all the tools in GitLab. “By using GitLab, we could hit the ground running, and keep the scale small. You don’t have to worry about all kinds of CI/CD operations and integrations and the configuration of that but use it just out of the box,” he says. How Blonk is utilizing GitLab today Currently, Blonk has 38 GitLab premium licenses, about half of which are used by software developers. The rest are used by data scientists, consultants, project managers, and others, so there are different ways the platform is utilized within the company; that also means there are different levels of software literacy but that hasn’t been an issue. The software development team has been onboarding very junior developers over the past couple of months, and “never have I had questions of how to do stuff in GitLab, because the platform is very intuitive,” Durlinger says. The software development team has been integrated further into the core business, which also fits nicely with GitLab’s services, including the milestones Blonk uses as well as its repositories and project management strategies. “Also data scientists and methodology developers are now […]

President Joe Biden last year on May 12th signed Executive Order 14028 “Improving the Nation’s Cybersecurity”, which called on public and private sector organizations to improve the nation’s cybersecurity with “bold change” and “significant investments”. “Incremental improvements will not give us the security we need,” the EO states. Since then, the administration has only increased the pressure on agencies, forcing them to take a hard look at their software supply chains and justify their application development decisions, including how they use open source code, test their code, and grant permissions. “The federal government has accelerated its expectations for software supply chain security compliance, yet some organizations are still trying to understand how to broadly and proactively protect their software development,” says Joel Krooswyk, Senior Manager of Solutions Architecture at GitLab. “Agencies and their vendors have been focused on policy management and role-based access, but the federal government wants to go deeper and know where code is coming from and how to better secure it. They are quickly moving down the supply chain.” The interest in the origins of software code stems from the complexity of cyberattacks such as that carried out on SolarWinds, as well as the ongoing log4j and Spring4Shell vulnerabilities. “Intentionally malicious contributions can inject code that is literally opening the doors to hackers,” Krooswyk says. “However, agencies and vendors can’t just stop utilizing open source software and microservices. They need the ingenuity of the open source community.” GitLab is a proponent of open source and believes everyone can contribute. The Biden administration, through its frameworks and mandates, is simply saying, ‘we have to keep a better eye on that,’ especially as more organizations assume a cloud-first posture, according to Krooswyk. For example, earlier this year, the National Institute of Standards and Technology (NIST) published the Software Security Development Framework (SSDF) 1.1, which offers guidance on how to create tighter controls throughout the software development lifecycle. The SSDF 1.1 framework recommends: organizations should be prepared by reviewing permissions all components of software should be safe from tampering and unauthorized access software should be produced with minimal security vulnerabilities in its releases organizations should be able to quickly and sufficiently respond to vulnerabilities Take our 2022 DevSecOps survey and get a $10 gift card. Have your voice count! Code sourcing The next phase in the federal government’s move to secure the software supply chain will be to require reporting and/or attestation. “Agencies and their vendors are being asked if their software is justifiably built using properly sourced code. As a result, organizations may have to explain why they chose to use code from non-mainline repositories,” Krooswyk says. For instance, if a DevOps team chooses code from a non-mainline repository originating in China, they will have to attest to why they did that over sourcing from a mainline repository. The same idea applies to pulling clean containers and not repeatedly using those plagued with existing vulnerabilities, according to Krooswyk. He believes these questions will all be rolled up into a Cybersecurity & Infrastructure Software Agency (CISA) mandate for a software bill of materials (SBOM), which is ​​a list of ingredients that make up software components. “The SBOM will show the list of contributors, known vulnerabilities, results of dependency scans on open source, and more,” he says. “The Biden administration, NIST, […]

Application security testing (AST) is a fast-moving and important area for software development. DevOps methodologies have spurred the need to integrate testing within the developer’s workflow. GitLab believes the more ingrained AST is in the software factory, the more secure applications will be and the easier it will be for companies to meet compliance demands. We believe our strategic platform approach, where security and compliance are embedded in DevOps from planning to production, provides efficiency and value unmatched by traditional application security vendors. Gartner® has named GitLab a Challenger in the 2022 Gartner Magic Quadrant™ for Application Security Testing. According to Gartner, “a major driver for the evolution of the AST market is the need to support enterprise DevSecOps and cloud-native application initiatives.” “We are excited to see continued momentum for our unique approach that embeds security into the DevOps workflow,” says Hillary Benson, GitLab director of product management. This is the third year that GitLab has been recognized in the Gartner Magic Quadrant for Application Security Testing. “We believe that our recognition as a Challenger in the Magic Quadrant represents an evolving market understanding of the value of an approach that empowers and enables developers to find and fix vulnerabilities – and the simplicity of leveraging a DevOps platform to do so.” You can read more about the results and download a copy of the report by visiting our commentary page. GitLab’s complete DevOps platform approach provides automation needed by DevOps, along with policy and vulnerability management needed by security professionals. GitLab’s Ultimate tier provides an integrated, vetted, and managed set of scanners to meet the security and compliance needs of modern-day application development and cloud-native environments. A unique approach to AST We continue to innovate in the application security space. Let’s look at how we’re different from many of the more traditional stand-alone AST technologies. It’s these very differences that provide benefits achievable by using a single platform for DevOps and security. For example: We build comprehensive scans into the CI pipeline to enable a more interactive testing environment. This is a unique approach as others in the category focus their offering on instrumentation-based interactive AST. With GitLab, the developer gets a more complete view of the security flaws as they are created – when they are most efficiently resolved. Similarly, while analysts place emphasis on lightweight spell-check-like SAST features, we have found that these features are less important to GitLab users, again because of our built-in approach. A metaphor may be helpful to explain. We are all accustomed to saving documents frequently so edits are not lost. Developers do the same while editing software. Changes made are “committed” frequently to the code repository. Upon hitting the ‘commit’ button, GitLab performs a true, SAST scan on code changes, which gives developers instant and more complete feedback. And DevOps teams can choose to enable DAST scanning that uses GitLab’s review app feature to assess changes pre-merge. Similarly, dependencies, containers, infrastructure as code, and more can all be scanned, at the push of the commit button. In addition, GitLab also is keen on providing DevOps teams just-in-time education about vulnerabilities and fixes. Now, via partnerships with Kontra and Secure Code Warrior, GitLab provides developers with crisp training on how to mitigate the specific vulnerability they just created. This helps developers […]

In fall 2021 we launched our second annual DevOps in Education Survey. Over 460 respondents from all regions of the world shared insights on how DevOps and GitLab are transforming higher education. Key findings One platform for the win: Respondents’ enthusiasm for teaching GitLab’s single DevOps platform increased 190% over 2020; survey takers also pointed to the way GitLab can tie culture to operations as key (up 189% year over year), and they also value student portfolio management (up 200%). CI/CD success: Academic institutions reported high rates of adoption of GitLab’s CI/CD features both within the classroom and in all other use cases. Flexibility is key: Deployment flexibility stands out again as a major advantage of GitLab at institutions of higher education. Security and authentication are the primary drivers. GitLab spreads the DevOps love: Multiple departments within an academic institution are reporting they’re now using GitLab and 21% of respondents said the ability to install multiple instances across a campus was a GitLab advantage (up 6% from 2020). …and more spread = branching out: Because GitLab has one complete platform, higher ed. respondents report they’re expanding their DevOps footprint to include additional stages like Secure. The three most used stages in education continue to be Source Control Management, Plan, and Verify. Release and Package are also seeing nearly 30% adoption by respondents. Planning features: Educators find planning features such as multi-level epics, issue tracking features, labels, and project management highly useful tools. Why DevOps belongs in the classroom The benefits of teaching or learning GitLab came through clearly in the survey. The fact that GitLab is a single DevOps tool was key for 58% of respondents, up from just 20% in 2020. What are the benefits of teaching or learning GitLab? How GitLab in education works Deployment flexibility is critical to universities because security and server access can be controlled (81%), all while integrating with user authentication systems (54%). The ability to host multiple instances per institution was also a factor for 21% of respondents, up 6% from last year – another sign that cross-campus adoption is growing. Advanced features (only available in the Ultimate tier) are used by 35% of respondents, which remained fairly consistent from 2020. Security features including container scanning, SAST, advanced security testing, custom DAST, and compliance management were among the most frequently mentioned. Multi-level epics and free guest users were commonly mentioned as well. Use cases and DevOps stages The most common use of GitLab in education was source control management with 53% of respondents actively using, followed by Verify (Continuous Integration) at 40%, Plan (issue tracking, labels) 38%, Manage (authentification, compliance management) at 28%, Package 29% and Release (Continuous Delivery) at 29%. The top four tools other than GitLab used by respondents were GitHub (76%), GitHub Actions (24%), Jenkins (26%), and BitBucket (17%). Faculty respondents noted the value of bringing industry tools to the classroom. One wrote, “Thank you for the GitLab Program. It makes it possible for us to manage students’ software engineering projects in a modern development environment.” Leveraging GitLab to boost skills The 2021 survey asked an additional question regarding what specific skills are being taught with GitLab in the classroom. The three top skills taught with GitLab are: CI/CD (40%), collaboration and communication (36%), application development and design (30%). Other […]