Petes Linkedin Blog

How DevOps and NFS changed the game What if I told you that one of the best-selling racing video game franchises of all time, the "Need For Speed" (NFS), and DevOps have more in common with each other than you think? Yes, you read that correctly, probably not the NFS (Network File System) you were expecting. An appetite for change For context, the NFS series originally set out to redefine a saturated, yet unsophisticated, racing video game market. Motivated by an appetite for change, the NFS user experience reflected the human connection to real cars and how they behaved, which was a big challenge for developers in the 1990s. Nearly 30 years ago, "The Need for Speed" forever changed the landscape of racing games, selling 150 million copies since its debut. The original Need For Speed video game set a new standard with an appetite for industry change. Coincidentally, it was in 1994 that Grady Booch coined the term "continuous integration" (CI). Booch,...

CI/CD is a foundational piece to modern software development. It's a major brick in the DevOps "Automation" pillar and every company involved in IT has to implement CI/CD or they're already quite far behind the curve. But implementing CI/CD can be challenging especially for growing or large companies. Some of those challenges include: DevOps expertise and technical skills DevSecOps Standardization Three key hurdles that come with implementing CI/CD This blog post unpackes these challenges and explains how Orange overcame them using GitLab. DevOps and technical skills No matter which CI/CD tool you're using, it requires some amount of expertise to implement it right. DevOps expertise is important because your team needs some experience with Git workflows, deployment, environments, secrets management, etc. You can't ask a complete rookie to implement a state-of-the art DevOps pipeline without expertise or experience. Technical skills are also impo...

The importance of container image security Thanks to containers, what it means to "ship software" has changed dramatically. Engineering teams have shifted to produce container images and use these container images to deploy their software. Because of this change teams are now shipping significantly more software alongside their app – whether they realize it or not. Besides packaging an application, container images also include hundreds of binaries and libraries. These binaries and libraries are included in the container image produced by the team because the process of creating a container image requires teams to select a base image. A base image is a preexisting container image on which to "base" their own container image. In doing so, all software contained in the base image is inherited into the team's new image. The shift to containers has a monumental impact on security. Now, anyone that deploys your team's container image could be deploying softwar...

Today we are releasing version 14.1.1 for GitLab Community Edition and Enterprise Edition. This version resolves a number of regressions and bugs in this month's 14.1 release and prior versions. GitLab Community Edition and Enterprise Edition Available in GitLab Free, Premium, and Ultimate: Extend RackAttack basic authentication detection for rate limiting Enable bulk dismissal checkboxes on group vulnerability report" Fix syntax highlighting inline background on darkmode Fix: Sidekiq workers delete each other's metrics Prevent terms from being created if blank Remove backfill migration for ci_build_trace_sections Geo: Fix snippet verification by replicating the HEAD ref Remove securityScansSucceeded from DevOps adoption Fix markdown in development docs Fix deployer task Don't ask users to upgrade to PG 13 yet Important notes on upgrading This version does not include any new migrations, and for multi-node deployments, should not require any downtime...

Cloud native application architectures use containerization, microservices, and Kubernetes to run reliably at cloud-scale. With a built-in container registry and Kubernetes integration, GitLab is the best way to develop and deploy cloud native applications. GitLab version 14.1 also includes a Helm registry, which allows users to publish, install, and share Helm charts and packages from within our single application for the entire DevOps lifecycle. What is Helm? Helm is a package manager for Kubernetes. A Chart is a Helm package that contains the resource definitions required to run an application inside a Kubernetes cluster. Helm allows you to manage complex applications by storing the application definition in a chart that can be versioned, shared, and collaborated on. The differences between Helm Registry and Git Why not simply store your Helm charts in a Git repository? After all, charts are YAML files that can be stored, versioned, and collaborated on like code. For small pro...

In part one of our GitOps series, we described how to use a pull-based (or agent-based) approach. In this second blog post, we'll dig deep into how to use a push-based approach. The agentless approach may be preferable for situations with non-Kubernetes infrastructure components or when you don't want to install, run, and maintain agents in each infrastructure component for GitOps. In this post, we will discuss how the scripting capabilities of GitLab can be used in GitOps workflows, and how to use predefined GitLab variables to shape infrastructure components. About a push-based or agentless approach With the agentless approach, infrastructure expressed and managed as code on GitLab, and updates and drift detection are automated and handled by GitLab without having to install any agents on infrastructure components. How to use scripting in your pipelines to shape infrastructure GitLab allows automation using scripting. Whether you're using Docker, Helm, Ansible, or ev...

Modern programming ecosystems make code reuse exceptionally easy. No matter the programming task at hand, chances are there is a package in a public registry such as rubygems.org or npmjs.com that implements that task. While the reuse of publicly available packages reduces the time necessary to write an app, this reuse brings its own set of challenges. Apps quickly depend on hundreds of packages, and programmers often simply just trust that these packages don't contain malicious code. In an ideal world, all depended-upon code is thoroughly vetted before being included in a program – however, this is often unfeasible in practice due to the sheer amount of dependency code that needs to be reviewed and the lack of existing tools to help with vetting dependency code. Malicious code in the wild Past incidents like malicious code in the popular package event-stream demonstrate that threat actors actively use public package registries as a distribution channel for malicious code. Thi...

Today, we are excited to announce the release of GitLab 14.1 with the ability to build, publish, and share Helm charts , create escalation policies to page responders , connect GitLab Runners to your Kubernetes clusters , enforce code coverage decisions , and much more! These are just a few highlights from the 50+ improvements in this release. Read on to check out all of the great updates below. To preview what's coming in next month’s release, check out our Upcoming Releases page , which includes our 14.2 release kickoff video. Join us for GitLab Commit Virtual to learn how DevOps teams increase collaboration. This month's Most Valuable Person ( MVP ) is Andrew Smith Andrew actively contributed numerous merge requests in the GitLab 14.1 release to help improve GitLab’s planning capabilities. He was able to make some significant improvements to GitLab’s issue and epic boards. Thanks to his work, GitLab users are now able to sort epic lists by title ; view the number o...