Petes Linkedin Blog

   This blog post is Unfiltered    Why read open source? When folks write about open source, I think there is a strong emphasis on contributing to open source projects, which makes sense. Many software professionals are excited to give back to the community. But beyond adding to your favorite project, open source philosophies have a number of other benefits in our daily lives. In particular, I love open source because it allows me to learn more about my tools when the documentation is out of date, incomplete, or leaves me with additional questions from my own curiosity. This happened to me recently when I was working on https://about.gitlab.com , a static site built with Middleman . I needed to find a more comprehensive list of available callbacks in the Middleman lifecycle. I hope this blog post is helpful if you're looking for existing Middleman callbacks, or if you're getting started reading through the source code of your favorite open source tools. The t...

As critical software projects grow, scaling infrastructure to make the service highly available is key. At GitLab, our biggest struggle in scaling was right in our name: Git. The trouble with scaling Git Git is software that is distributed, but not usually run in a ‘highly available cluster,’ which is what GitLab needs. At first, we solved this with a boring solution , NFS – which exposes a shared filesystem across multiple machines and generally worked. As we’d soon find out, most NFS appliances were for bulk storage and not fast enough. This led to problems with GitLab’s Git access being slow. To solve the speed problem we built Gitaly, our service that provides high-level RPC access to Git repositories . When we started with Gitaly v1.0 , our goal was to remove the need for a network-attached filesystem access for Git data. When that was complete, the next problem to tackle was that all your data is only stored once. So, if you have a server down, or your hard disk dies, or som...

At GitLab, we must verify simultaneous changes from the hundreds of people that contribute to GitLab each day. How can we help them contribute efficiently using our pipelines? The pipelines that we use to build and verify GitLab have more than 90 jobs. Not all of those jobs are equal. Some are simple tasks that take a few seconds to finish, while others are long-running processes that must be optimized carefully. At the time of this writing, we have more than 700 pipelines running . Each of these pipelines represent changes from team members and contributors from the wider community. All GitLab contributors must wait for the pipelines to finish to make sure the change works and integrates with the rest of the product. We want our pipelines to finish as fast as possible to maintain the productivity of our teams. This is why we constantly monitor the duration of our pipelines. For example, in December 2020, successful merge request pipelines had a duration of 53.8 minutes : The aver...

   This blog post is Unfiltered    🚀 Your DevOps journey, like any good space journey, spans vast distances. As your space captain, I’m here to remind you, we have a long way to go. DevOps by its continuous improvement definition isn’t a one stop destination. Today, in the true spirit of continuous improvement we’re rightly focused on our immediate next step along the journey. The next steps involve familiar friends - our fellow technical professionals who design, code, test, secure, deploy and operate software. On our space journey they are our local solar system - they’re Mercury, Venus, Earth, Mars, Jupiter and Saturn. These planetary neighbors are concentrating on improved feedback and collaboration amongst each other. We’re optimizing the efficiency of software creation. We’ve even built complete teams to perform this integrated activity holistically. That is DevOps culture! That is also just the beginning of DevOps. In DevOps we call this solar-system colla...

   This blog post is Unfiltered    At GitLab, we’re all about iteration . It helps us continuously push out product improvements and additional value to our users. One interesting side effect of iteration is that it can make it harder to see the true scope of what you’ve delivered. Rather than a few big bang giant feature releases per year, a steady flow of iterative improvements requires taking a few steps back to look at all the work in aggregate to get a full sense of accomplishment. As we look forward to 2021, it’s worth a look back to see how far the Threat Insights group has come with Vulnerability Management in the past year. The year 2020 was filled with unprecedented challenges far beyond what most of us have ever experienced. The Threat Insights team formed against a backdrop of uncertainty with a global pandemic just starting to spread. Most of our team joined GitLab last year. We took over a fledgling area of the product that was off to a good start ...

   This blog post is Unfiltered    Are you curious about our Secure offerings? They are easy, and free, to try out! I suggest you create a free demo project to check them out and see if it's something you might want. Did you know? If you have a public project on GitLab.com you can enable our Secure scanning functionality. Please note that educational institutions and open-source projects can also request free licenses. In this blog I will walk you through creating a new demo project, adding Dependency Scanning, and reviewing the results of the scan. Following the steps below should take you 15 minutes. Create a test project Let's grab a test project and enable Dependency Scanning. Sign in to your GitLab account. Create a new project by clicking "New project" on your project list . Select the "Create from template" option. Select a project template. Be sure to choose one that is written in one of our supported languages and package managers . I...

Today we are releasing versions 13.7.4, 13.6.5 and 13.5.7 for GitLab Community Edition (CE) and Enterprise Edition (EE). These versions contain important security fixes, and we strongly recommend that all GitLab installations be upgraded to one of these versions immediately. GitLab releases patches for vulnerabilities in dedicated security releases. There are two types of security releases: a monthly, scheduled security release, released a week after the feature release (which deploys on the 22nd of each month), and ad-hoc security releases for critical vulnerabilities. For more information, you can visit our security FAQ . You can see all of our regular and security release blog posts here . In addition, the issues detailing each vulnerability are made public on our issue tracker 30 days after the release in which they were patched. We are dedicated to ensuring all aspects of GitLab that are exposed to customers or that host customer data are held to the highest security standards...