TechPrufer
Get started
GitLab
GitLab logoGitLab · Feature trail

DevOps Platform Evolution

80 posts · Jun 2014 – Nov 2025

What this trail covers

GitLab's DevOps platform is being extended to support mainframe development environments through a partnership with IBM. This involves providing native z/OS Runner support for CI/CD pipelines that execute directly on IBM z/OS infrastructure. The solution aims to unify source code management by replacing legacy library managers with GitLab's repository system, and integrates with IBM Developer for z/OS Enterprise Edition (IDzEE) for dependency-based builds, automated code scanning, and debugging. This enables end-to-end visibility across mainframe and distributed environments, facilitating incremental modernization and hybrid cloud strategies.

All GitLab trails
  1. Deploying the world's largest GitLab instance 12 times dailyThis post details the technical implementation of deploying the world's largest GitLab instance up to 12 times daily without downtime. It outlines the CI/CD pipeline architecture, including code flow, build processes (Omnibus packages and CNG images), and environment-based validation with a canary strategy. Specific technical details include the progressive rollout strategy (Staging Canary, Production Canary, Staging Main, Production Main), QA validation checkpoints, and the deployment pipeline stages: Prep, Migrations (Canary stage only), Assets (Canary stage only), Gitaly (using Omnibus and tableflip for atomic upgrades), and Kubernetes (via Helm chart across multiple clusters). It also addresses the challenge of multi-version compatibility during deployments where database schema changes precede code updates in different environments.
  2. Why now is the time for embedded DevSecOpsThis post details the application of DevSecOps principles to embedded systems development, driven by market forces like the software-defined product revolution, hardware virtualization, and competitive/economic realities. It outlines priority transformation areas: automating compliance and security governance using frameworks and CI/CD, and enabling collaborative innovation through shared code visibility and integrated workflows. It specifically mentions the use of GitLab's On-Premises Device Cloud for orchestrating firmware tests on virtual and real hardware, reducing feedback cycles and catching bugs earlier. It also emphasizes automating compliance with standards like ISO 26262 or DO-178C and integrating specialized tools into CI pipelines.
  3. GitLab Ultimate for IBM Z: Modern DevSecOps for mainframesThis post introduces GitLab Ultimate for IBM Z, a new offering that extends GitLab's DevSecOps platform to IBM mainframe environments. Key technical contributions include native z/OS Runner support for CI/CD pipelines, enabling direct execution on z/OS infrastructure. It also details the replacement of legacy mainframe library managers with GitLab's searchable, version-controlled repository system and integration with IBM Developer for z/OS Enterprise Edition (IDzEE) for enhanced build, scan, and debug capabilities. The goal is to provide unified development environments and end-to-end visibility across mainframe and distributed systems.
  4. Create a workspace quickly with the GitLab default devfileIntroduces a default devfile for GitLab Workspaces, eliminating the need for users to manually create a custom devfile for basic workspace setup. This simplifies the onboarding process for new users and projects by providing a pre-configured environment with the GitLab VS Code fork and Workflow extension.
  5. Enable secure sudo access for GitLab Remote Development workspacesThis post introduces the capability to enable secure sudo access for GitLab Remote Development workspaces. It details the challenge of restricted sudo access in containerized environments and presents three methods for enabling it: Sysbox, Kata Containers, and user namespaces. Each method includes specific configuration steps for the GitLab agent and Kubernetes cluster. The post also demonstrates how to use the enabled sudo access to install and use `jq` for log analysis.
  7. Managing GitLab resources with PulumiThis post introduces the use of Pulumi for managing GitLab resources, specifically focusing on automating CI/CD pipeline setup and integrating with AWS via OIDC for secure credential management. It details the setup of a Pulumi project using TypeScript, the GitLab and AWS providers, and the creation of GitLab projects, project variables, and AWS IAM roles and OIDC providers. It also outlines the optional setup of a Pulumi project hook for merge request integration.
  8. U.S. Navy Black Pearl: Lessons in championing DevSecOpsThis post details the implementation of the 'Black Pearl' DevSecOps environment for the U.S. Navy, managed by Sigma Defense. It highlights how consolidating multiple software factories into a single managed environment using GitLab has led to significant reductions in setup time, cost, and improved security through Authorization to Operate (ATO). Key technical aspects include the use of GitLab as a 'one-stop shop' for SCM, tasks, documentation, and security scanning, enabling collaborative efficiency and faster go/no-go decisions. The post emphasizes the importance of a strong development ecosystem, centralized security and compliance (leveraging GitLab Ultimate for templating and baking compliance in), rapid talent onboarding, and flexibility in delivery environments. It also touches on the potential for AI/ML integration and the need for novel tools and data classifications.
  9. Atlassian Server ends: Time to move to integrated DevSecOpsThis post highlights the end-of-life for Atlassian Server products (Bitbucket Server, Bamboo Server, Jira Server) as a catalyst for migration to a unified DevSecOps platform. It emphasizes GitLab's importer tools for repositories, Jira issues, and Bamboo jobs, and details the benefits of a single platform: reduced complexity, increased productivity, improved developer experience, and enhanced visibility across the software development lifecycle. It positions GitLab as an AI-powered DevSecOps platform that consolidates toolchains, leading to cost and time savings, increased efficiency, and better security.
  10. 6 reasons Cisco Learning and Certifications adopted GitLabThis post details how Cisco Learning and Certifications adopted the GitLab DevSecOps Platform to address challenges in version control, accountability, toolchain consolidation, collaboration, and production speed. Key benefits highlighted include centralized version control, transparent accountability through merge requests and branching, reduced toolchain complexity by consolidating source control, CI, and issue tracking, improved collaboration via a single platform, and faster time-to-production by optimizing the idea-to-working-software cycle. The post also touches upon the potential impact of AI on software creation and developer learning, including concerns about intellectual property and the learning curve for new engineers.
  11. Disagree, commit, and disagree: How a lazy solution became a categoryThis post details the origin story of GitLab's DevOps Platform category, tracing its evolution from a developer collaboration tool to a comprehensive platform. It highlights the key decision to integrate Source Code Management (SCM) and Continuous Integration (CI) as a pivotal moment that shifted the company's trajectory and influenced the industry towards integrated DevOps solutions. The narrative emphasizes the 'disagree, commit, and disagree' principle as a driver for innovation, allowing for the discovery and creation of new market categories.
  12. How GitLab helped Fedora build websites and communityThis post details how the Fedora Project migrated its website development workflow to GitLab, leveraging its integrated platform for planning, implementation, and deployment. Key technical contributions include: rewriting the technology stack using NuxtJS and NetlifyCMS, automating deployment workflows with GitLab Pages for staging environments and community infrastructure for production, and utilizing CI/CD for ephemeral deployment environments triggered by pushes to the primary branch or merge requests. The adoption of GitLab simplified and standardized workflows, reducing reliance on disparate tools and improving contributor experience by lowering the barrier to entry for documentation and translation contributions.
  13. GitLab, AWS help strengthen Lockheed Martin’s digital transformationThis post details how Lockheed Martin adopted GitLab's DevSecOps Platform on AWS to accelerate their digital transformation (1LMX initiative). Key technical contributions include: automating and optimizing code deployment using Infrastructure as Code (IaC) for faster environment provisioning (2 hours vs. several hours), establishing automated, highly available, and disaster recovery-compliant architectures, implementing load balancing for auto-scaling based on demand, and integrating monitoring and security controls. These efforts resulted in reduced build request queues and faster code deployment across the enterprise.
  14. How GitLab and Google Cloud drive innovation and efficiency for retailersThis post details how GitLab's DevSecOps Platform integrates with Google Cloud's Distributed Cloud Edge and Anthos to enable retailers to manage hybrid and multicloud environments. It highlights capabilities such as Agile planning for Anthos cluster configurations, CI for code quality, configuration management for rollbacks, and native integration with Google Cloud for faster and more secure deployments. A specific use case demonstrates automated deployment at scale for retailers, syncing configurations and data across Google Cloud, other clouds, and on-premises environments, enabling retailers to scale hybrid Anthos clusters with Google Distributed Cloud Edge machines. Configurations are stored as YAML files in GitLab repositories, and Anthos Configuration Management retrieves and applies them to Google Distributed Cloud Edge nodes.
  15. Cube reduces toolchain complexity and speeds software delivery with GitLabThis post details how Cube, a software development company, migrated from a fragmented toolchain (Bitbucket, Trello, Jira) to GitLab's all-in-one DevSecOps Platform. Key technical contributions include: improved CI/CD delivery speed through automated pipelines and runners for linting, unit/functional tests, and deployments; facilitated rollbacks; easier on-premises GitLab Runner configuration; enhanced Agile capabilities with epics and milestones for managing releases and project management; integration of Sentry for error monitoring; and the use of GitLab for 90% of project management and working functionalities. Success is measured by lead time of delivery and efficiency of development phases.
  16. Vestiaire Collective's DevSecOps migration: Wins and insightsVestiaire Collective migrated from Subversion to GitLab for version control, code reviews, and CI/CD pipelines. They integrated GitLab's container registry, replacing external solutions like ECR and Nexus. The post highlights the benefits of GitLab's Jira integration for commit visibility and release syncing. The team is considering migrating project management entirely to GitLab issues and epics. They also plan to deploy GitLab into a Kubernetes cluster and explore GitLab's error tracking and feature flag capabilities.
  17. Put `glab` at your fingertips with the GitLab CLIThis post announces the adoption and integration of the open-source `glab` project into GitLab's native CLI experience. It details how `glab` will form the foundation for bringing GitLab functionality to the terminal, enabling developers to perform tasks such as reviewing issues, creating branches and merge requests, checking pipeline status, and approving/merging work without leaving the command line. The post highlights the collaboration with the original `glab` maintainer and the community, the transition process from GitHub Actions to GitLab CI, and the security review conducted by GitLab's application security team. It also provides installation instructions and details on authentication methods, including integration with 1Password Shell Plugins.
  18. How GitLab eliminates value stream friction in dev environmentsThis post details the challenges and negative feedback loops associated with developer environment lifecycle management, particularly concerning provisioning friction and environment sprawl. It introduces GitLab Review Environments as a solution that automates the provisioning and teardown of isolated, immutable environments per feature branch, directly addressing the value stream friction caused by environment management. The post emphasizes the benefits of treating developer environments as a complete lifecycle, from creation to retirement, and highlights the reduction in both hard dollar costs and opportunity costs.
  19. Oracle and GitLab partner for cloud-native app developmentThis post details a partnership between GitLab and Oracle to enable customers to run GitLab's DevOps platform on Oracle Cloud Infrastructure (OCI). It highlights the benefits of this pairing, including performance improvements, platform breadth (integrating with OKE and serverless functions), enhanced security features of OCI, value through end-to-end SLAs, and support for hybrid and multi-cloud environments. It also mentions OCI's GovCloud regions and how GitLab can be deployed on OCI using Oracle Linux packages, Helm charts, or the GitLab Operator for a cloud-native hybrid approach.
  20. Two DevOps platform superpowers: Visibility and actionabilityThis post introduces the concepts of visibility and actionability within a DevOps platform, highlighting how epics, issues, labels, dashboards, and value stream analytics contribute to these capabilities. It explains how these features enable teams to track projects, organize work, gain insights into workflow efficiency, and make immediate changes based on that information.
  21. GitLab is the single source of truth for eCommerce providerThis post details Swell's adoption of GitLab as their unified DevOps platform, highlighting their use of CI/CD, review operations for creating per-merge-request environments, and container management. It also covers their use of GitLab for issue tracking, knowledge management, and support ticketing, emphasizing the benefits of a single source of truth for a fully remote organization. The post notes significant speed improvements in build and deploy times and the integration of security scanning tools.
  22. Battling toolchain technical debtThis post discusses the concept of toolchain technical debt and how a unified DevOps platform like GitLab can help mitigate it. It highlights the challenges of fragmented, homegrown toolchains and the benefits of adopting a purpose-built platform for simplicity, control, and visibility across the SDLC. It also mentions specific GitLab features like dependency lists (SBOM) for security scanning and value stream analytics for optimizing IT resources.
  23. GitLab provides small business with a professional, mature DevOps platformThis post details how Blonk, a small business, adopted GitLab as its integrated DevOps platform to manage project management, CI/CD, repositories, and version control. It highlights their use of GitLab Premium for developers, data scientists, consultants, and project managers, leveraging features like issue templates, package registry, Docker integration, and automated infrastructure deployment via CDK and gitlab-ci scripts. The post emphasizes the platform's intuitive nature, its role in scaling the development team, and the integration of non-code artifacts within projects. It also touches on how GitLab has supported Blonk's business transformation by providing a professional project creation pipeline and enhancing their employer brand.
  24. The best of GitLab's DevOps Platform 2021This post highlights several key additions to GitLab's DevOps Platform in 2021: Epic Boards for project management, enhanced VS Code and Gitpod integrations for developer workflows, a new security dashboard and SAST upgrades (including IaC scanning), Praefect for Gitaly HA, a visual pipeline editor, OpenShift runner support, and the GitLab Agent for Kubernetes. It also signals a future focus on observability.
  25. How to bring DevOps to the database with GitLab and LiquibaseThis post introduces and demonstrates the integration of Liquibase with GitLab CI/CD for automated database change management. It details the setup of a CI/CD pipeline with stages for build, test, and deploy, showcasing specific Liquibase commands like `checks run`, `updateSQL`, `update`, `rollbackOneUpdate`, `tag`, `diff`, and `snapshot`. The tutorial covers prerequisites, project preparation, runner configuration, making database schema changes, and merging to trigger the pipeline, highlighting the use of CI/CD variables and Liquibase Pro features.
  26. GitOps with GitLab: Connect with a Kubernetes clusterThis post introduces and details the setup of the GitLab Agent for Kubernetes, a new capability for connecting Kubernetes clusters to GitLab. It explains the agent's architecture, registration process (UI and Terraform), and installation using `kpt` and `kustomize`. The post focuses on enabling GitOps workflows by establishing a bidirectional GRPC channel between the agent and GitLab for enhanced integrations.
  27. How to install and use the GitLab Kubernetes OperatorThis post details the installation and configuration of the GitLab Kubernetes Operator on an OpenShift Container Platform cluster. It covers the prerequisites (Prometheus, cert-manager), the application of the Operator CRD, and the creation of a GitLab instance using a Custom Resource file. It also outlines how to obtain the initial root password and log in to the newly deployed GitLab instance.
  28. Deprecating cert-based Kubernetes integration in GitLab 14.5This post announces the deprecation of the certificate-based Kubernetes integration, which was introduced in GitLab 10.4. It highlights the security risks and limitations of the old method, such as requiring cluster-admin privileges and lack of fine-grained access control. The post introduces the GitLab Agent for Kubernetes, released in GitLab 14.5, as the recommended replacement, emphasizing its advantages in security, reliability, scalability, and functionality, including support for GitOps and bi-directional communication. It outlines the migration path, deprecation timeline (GitLab 15.0 for GitLab.com, later for self-managed), and future roadmap for the Agent, including observability and Auto DevOps improvements. Users are encouraged to provide feedback on migration priorities.
  29. GitOps delivery by connecting Kubernetes clusters to GitLabThis post introduces a series on GitOps delivery using GitLab, focusing on provisioning infrastructure with Terraform, connecting Kubernetes clusters via the GitLab Agent, secrets management, and application deployment with Auto DevOps. It provides context on DevOps, SRE, IaC, and containers, and outlines the upcoming tutorials in the series.
  30. GitLab's Kubernetes Operator for OpenShift now availableThis post announces the general availability (GA) of the GitLab Operator, enabling production instances of GitLab to run on Kubernetes platforms, including Red Hat OpenShift. It explains the motivation for building the operator, highlighting the need to support enterprise-grade Kubernetes distributions like OpenShift and the operational overhead of managing legacy infrastructure. The post details how the Operator pattern automates administrative knowledge for deployment and operation, and how it expands beyond the existing GitLab Helm Chart by actively securing deployments and ensuring continuous updates. It also mentions that the Operator runs on both Red Hat OpenShift and vanilla Kubernetes.
  31. How ten steps over ten years led to the DevOps PlatformThis post reflects on ten years of GitLab's development, highlighting key decisions that shaped its evolution into a DevOps platform. It emphasizes 'work in parallel' philosophy, CI/Git integration, cloud-native adoption (Kubernetes, microservices), the centrality of merge requests for all workflows (including security checks), developer-first security, a complete definition of security beyond SAST/DAST, the all-remote culture, asynchronous communication, visibility across the DevOps lifecycle, and the importance of measuring results. These decisions collectively contribute to the platform's comprehensive nature and its ability to support modern DevOps practices.
  32. How to deploy the GitLab Agent for Kubernetes with limited permissionsThis post details the deployment of the GitLab Agent for Kubernetes (`agentk`) with limited permissions. It covers the architecture of `agentk` and its communication with the GitLab Agent Server (KAS), and provides a step-by-step guide for deploying the agent with specific namespace access controls using Kubernetes RBAC (Roles, RoleBindings, ClusterRoles, ClusterRoleBindings). It demonstrates how to limit the agent's access to specific namespaces ('dude') while denying access to others ('naww'), and how to configure service accounts and deployments for this limited scope.
  33. Using push-based GitOps with GitLab scripts and variablesThis post details how to use a push-based GitOps approach with GitLab scripts and variables for managing infrastructure. It demonstrates using Docker, kubectl, Helm, and Ansible within GitLab pipelines to create, shape, and modify infrastructure components. It also shows how to use project/group variables and Auto DevOps to modify infrastructure, such as adjusting the number of production pods in a Kubernetes cluster. The post highlights the benefits of this agentless approach for non-Kubernetes infrastructure and for integrating IaC tools.
  34. Are you ready for the newest era of DevSecOps?This post introduces the concept of DevSecOps 2.0, emphasizing that security must be an integral part of the DevOps platform, not just an add-on. It highlights the need for end-to-end visibility and control throughout the SDLC, moving beyond 'shifting security left' to include testing, monitoring, and protecting application infrastructure and IaC. The post also mentions the evolution of security dashboards and vulnerability reports for streamlined management and remediation, and the importance of compliance management as a key part of DevSecOps 2.0.
  35. GitOps viewed as part of the Ops evolutionThis post frames GitOps as a summary of best practices that have evolved over the past 20 years in operations, rather than a new concept. It traces the evolution from System Administrators to SRE at Google, the rise of public cloud and Infrastructure as Code, the emergence of DevOps, and the impact of containers and Kubernetes. It positions GitOps as the culmination of these trends, emphasizing the combination of DevOps culture, automation, and declarative infrastructure management provided by Kubernetes. It also highlights GitLab's role in supporting these practices through its CI/CD and IaC capabilities.
  36. Modern DevOps shift in GitLab 14: Speed, trust & visibilityThis post announces GitLab 14, highlighting advancements across the DevOps lifecycle. It emphasizes velocity with confidence through a complete DevOps platform, including the Pipeline Editor for CI/CD and the Kubernetes Agent for secure cloud-native deployments. It also discusses visibility into DevOps success with DORA metrics and Value Stream Analytics, and built-in security features like Semgrep and a new DAST crawler. The post also touches on the company's remote work culture and the contributions of its open-core model and community.
  37. Agile planning with a DevOps platformThis post articulates the benefits of a unified DevOps platform, emphasizing how GitLab's single-application approach provides accuracy, visibility, efficiency, and actionability by integrating planning and execution. It highlights the shift from toolchains to platforms and mentions Gartner's recognition of this trend.
  38. We are very far from a better Heroku for production apps in a hyper cloudThis post introduces a '5 minute production app' template that leverages GitLab CI/CD and Terraform to automate the deployment of web applications to AWS. It demonstrates deploying a simple Node.js application by importing a GitHub repository into GitLab, configuring AWS credentials as CI/CD variables, and including a remote CI/CD template. The template provisions AWS resources, including a PostgreSQL server, Redis cluster, and S3 object storage (though these are disabled by default for the demo app). It highlights the benefits of using managed cloud services and IaC for simplified application deployment and persistence, contrasting this approach with the manual CLI-driven process of Heroku. The post also briefly mentions integrating dependency scanning and SAST into the pipeline.
  39. GitOps & DevSecOps for production infrastructure in minutesThis post details the 'Five Minute Production App' initiative, which demonstrates achieving production-grade infrastructure and DevSecOps workflows in under five minutes by converging AWS, Hashicorp Terraform, and GitLab. It outlines a three-stage process: Build (containerizing the application using Auto DevOps), Provision (using Terraform to create AWS resources like EC2, RDS, ElastiCache, and S3, tied to Git branches), and Deploy (retrieving the container image and infrastructure credentials to deploy the application, with automated SSL certificate generation via Let's Encrypt). The post emphasizes the complete GitOps convergence where application code, infrastructure as code, CI/CD, state, secrets, and environment configurations all reside within a GitLab project.
  40. How to deploy to AWS with GitLabThis post introduces and details GitLab's new official Docker images and CI/CD templates for deploying applications to AWS. It covers the AWS CLI Docker image, CloudFormation stack creation Docker image, Push to S3 and Deploy to EC2 Docker image, and CI/CD templates for ECS and EC2 deployments. It also highlights security considerations like predefined AWS CI/CD variables and immutable Docker image digests, and expands Auto DevOps support for non-Kubernetes AWS targets (ECS, Fargate, EC2). Future plans for AWS deployment support are also outlined.
  41. How a GitLab engineer changed the future of DevOpsThis post details the historical contribution of Kamil Trzciński's faster, more parallelizable, and easier-to-contribute-to GitLab runner, which led to GitLab deprecating its own runner and hiring him. It further elaborates on his pivotal suggestion to combine GitLab SCM and CI into a single application, thus defining the 'DevOps Platform' category. The post emphasizes the engineering rationale behind this unification, including reduced overlap, saved development effort, and increased efficiency for users, despite initial customer skepticism.
  42. GitLab enhances DevOps journey on Linux on IBM Z and Red Hat OpenShiftThis post details the integration of GitLab CI/CD with Linux on IBM Z and Red Hat OpenShift. It highlights the availability of GitLab Runner support for Linux on IBM Z and the development of the GitLab Runner Operator for Red Hat OpenShift, allowing cloud-native pipelines to run on these platforms. It also mentions the historical context of running GitLab on IBM Z and the ongoing collaboration between GitLab and Red Hat teams.
  43. Why GitLab is building Meltano, an open source platform for ELT pipelinesThis post announces the strategic direction of Meltano, focusing on building an open-source, self-managed platform for ELT (Extract, Load, Transform) data pipelines. It argues that data integration should be a commodity and that an open-source alternative is needed to compete with proprietary solutions. The post draws parallels with GitLab's open-core model and emphasizes the power of community collaboration to develop and maintain data source connectors (extractors and loaders). The core technical contribution is the strategic positioning and justification for building Meltano as a self-managed ELT platform, aiming to democratize data integration.
  44. How GitLab CI helps solve common DevSecOps challengesThis post explains how GitLab CI/CD addresses common DevSecOps challenges by providing a unified platform that eliminates silos, increases visibility across the SDLC, and improves efficiency by reducing the need for multiple tools and complex plugin environments. It highlights the benefits of a single application for CI/CD, contrasting it with the complexity of managing multiple tools and brittle pipelines.
  45. Deploying apps to GitLab-managed Amazon EKS with Auto DevOpsThis post details the integration of GitLab Auto DevOps with Amazon EKS for deploying applications. It outlines the steps to set up a project by importing a sample application and enabling the Auto DevOps pipeline. It also explains the deployment process, including the automatic creation of subdomains and the use of Let's Encrypt certificates. The post further describes how to make changes to a deployed application, including the use of merge requests, Review Apps for pre-production review, and the subsequent deployment to production upon merging.
  46. What's coming for Auto DevOpsThis post details upcoming improvements to Auto DevOps, focusing on enhancing its integration with Kubernetes and other GitLab features. Key upcoming changes include the adoption of Cloud Native Buildpacks, support for running Auto DevOps on air-gapped networks, an upgrade to Helm 3, integration of NGINX alerts into the auto-monitoring feature, and the addition of Merge Train support. It also mentions a future direction towards a Directed Acyclic Graph (DAG) approach for Auto DevOps pipelines.
  47. GitLab and Red Hat: Automation to enhance secure software developmentThis post details the integration of GitLab with Red Hat's RHEL and OpenShift platforms to enhance secure software development. It outlines how GitLab's CI/CD, AutoDevOps, container registry, and Kubernetes integration can be deployed on RHEL and target OpenShift. It also mentions upcoming product integrations like the GitLab Runner Operator for OpenShift.
  48. Why GitOps should be the workflow of choiceThis post introduces and advocates for GitOps as a convergence of infrastructure-as-code and continuous delivery, positioning it as the next iteration of DevOps. It highlights how GitOps enables a developer-like experience for managing applications and infrastructure by using Git as the central source of truth and integrating changes into the merge request workflow for collaboration and automated deployment via CI/CD pipelines.
  49. From monolith to microservices: How to leverage AWS with GitLabThis post details how Ask Media transitioned from a monolithic system to a microservices architecture using GitLab and AWS. Key technical aspects include leveraging GitLab for building images and as a command and control interface for Kubernetes clusters running on EC2 instances. The post highlights the benefits of microservices for independent development, parallel work, and full visibility prior to deployment. It also emphasizes the role of Docker and Kubernetes in enabling the microservices architecture and AWS for auto-scaling, cost control, and providing a mature platform with a wide range of services.
  50. How to leverage GitLab CI/CD for Google FirebaseThis post introduces the integration of GitLab CI/CD with Google Firebase for automated deployments. It details the process of initializing Firebase projects, configuring `firebase.json` for hosting, and setting up `.gitlab-ci.yml` to automate deployments of Vue.js applications, Firebase Functions, and Firestore rules. Key steps include acquiring a Firebase API token, configuring it as a protected and masked CI/CD variable in GitLab, installing the `firebase-tools` CLI in the `before_script` section, and defining separate deployment jobs for functions, Firestore, and hosting, triggered by changes in specific directories or branches.
  51. The problem with Git flowThis post introduces GitLab Flow as a streamlined branching strategy that integrates issue tracking with the Git workflow. It contrasts GitLab Flow with Git flow, highlighting the problems of unnecessary branch switching and complexity in Git flow. GitLab Flow emphasizes feature branches, a production branch, and the use of merge requests for code integration, with a focus on continuous integration and delivery. It also outlines 10 stages of software development and provides best practices for efficient development.
  52. From idea to production on thousands of cloudsThis post introduces Gravitational's Gravity, an open-source Kubernetes packaging solution, as a complementary technology to GitLab's CI/CD and Kubernetes integration. It explains how Gravity allows developers to build 'cluster images' that can contain an entire Kubernetes cluster pre-loaded with applications, enabling deployment across diverse environments (multi-cloud, private data centers, air-gapped rooms). The post highlights how GitLab can be used as the single source of truth for application development and continuous delivery, while Gravity handles the scaling and deployment to multiple environments.
  53. Announcing GitLab Serverless deploying to Cloud Run for AnthosThis post announces GitLab's collaboration with Google Cloud to support Cloud Run for Anthos, enabling CI/CD and GitLab Serverless capabilities for serverless solutions. It details three deployment options for Cloud Run: fully managed Cloud Run, Cloud Run for Anthos on Google Cloud, and Cloud Run for Anthos on-premise. GitLab's support for these involves using GitLab Runners to build and test functions and defining deployments via `serverless.yml` files. The post also highlights upcoming support for newer Knative versions and provides links to sample code and documentation.
  54. Simplifying and optimizing cloud native architecturesThis post introduces GitLab's design for cloud-native architectures, highlighting its integration with Kubernetes, built-in container registry, and advanced CI/CD features that support microservices and monorepos. It emphasizes workflow portability across multiple clouds and mentions native capabilities for Kubernetes integration and advanced deployment flows like progressive delivery and canary deploys, as well as built-in feature flagging.
  55. How Delta made the journey to cloud nativeThis post details Delta Air Lines' journey to cloud-native adoption, driven by the need for business agility. It highlights their tool selection criteria (AEIOU: Applicability, Enterprise-ready, Integration, Overhead, Usefulness) and their initial choices of GitLab, Sonatype Nexus, and Jenkins. The post emphasizes the benefits of this transformation, including improved customer experience through API development for check-ins and enhanced decision support for weather events, leading to cost savings and a better developer experience by enabling hybrid cloud usage.
  56. DevOps on the edge: Upcoming collaborations between GitLab and ArmThis post details the collaboration between GitLab and Arm to enable DevOps practices for edge computing. It highlights the use of GitLab for edge base research projects, enabling multi-architecture image creation using Docker and running GitLab Runners on Arm instances. It also mentions stream processing on the edge using Fluent Bit and participation in the CNCF CI Working Group for building and testing on both x86 and Arm architectures.
  57. Auto DevOps 101: How we’re making CI/CD easierThis post introduces Auto DevOps as a feature that simplifies CI/CD by providing a pre-configured pipeline that automates 12 software development steps. It highlights the 'shift left' philosophy by integrating code quality, security scanning (dependency, license, container), and dynamic application security testing (DAST) early in the development lifecycle. It also mentions Auto Deploy to staging/production, browser performance testing, and auto monitoring. The composable Auto DevOps option is introduced for greater flexibility.
  58. Redbox delivers On Demand with GitLabThis post details Redbox's adoption of GitLab to modernize their software development processes, speed up cloud delivery, and empower developers to own their applications. Key technical contributions include leveraging GitLab CI with Fastlane for modernized development, integrating GitLab CI with Spinnaker for faster cloud delivery, and using GitLab Enterprise for developer ownership of applications and cloud deployments. The post also highlights the consolidation of disparate Git and source control tools into GitLab, and the flexibility of GitLab CI to adapt to existing tools like Jenkins, Jira, JFrog Artifactory, and Spinnaker.
  59. MRI Technologies used GitLab for unified toolchains to NASAThis post details how MRI Technologies partnered with NASA to build the APPDAT platform using Kubernetes and GitLab. It highlights the migration from a legacy Oracle-based SCM solution to a modern, unified DevSecOps platform. Key technical aspects include the adoption of Kubernetes for cloud-native infrastructure, GitLab as the integrated source control management solution covering the entire DevSecOps lifecycle, and the establishment of a single source of truth for application development and data science. The post emphasizes the cultural shift towards open project management, collaboration, and a 'compliant by fault' security model, moving away from silos and piecemeal solutions.
  60. Is serverless the end of ops?This post analyzes serverless architecture, discussing its pros (less operational overhead, scalability, lower operating costs) and cons (less control, potential security risks, unpredictable costs). It argues that serverless is not the end of operations but rather a new way of managing systems that can be outsourced. The post also touches upon GitLab's exploration of integrating serverless functions with Knative and Kubernetes, and supporting serverless functions in AWS Lambda, alongside existing support for monoliths and microservices.
  61. Why GitLab uses one codebase for Community & EnterpriseThis post details the technical decision and process of merging the separate GitLab Community Edition (CE) and Enterprise Edition (EE) codebases into a single repository. It explains the challenges of maintaining two repositories, the benefits of a unified codebase (reduced complexity, fewer merge requests, improved developer experience), and the technical approach using Ruby module injection to manage proprietary code. The post also outlines the three potential project setup approaches considered and the final decision to move development into the gitlab-ee repository (renamed to gitlab-foss for CE users), detailing the impact on issues and merge requests.
  62. The market figured out GitLab’s secretThis post details the strategic decision and technical rationale behind merging GitLab Version Control and GitLab CI into a single application. It highlights the initial technical and product concerns, the eventual realization of efficiency gains and improved user experience, and how this consolidation enabled advanced automation features like auto-remediation for vulnerabilities. The post also notes the market's subsequent validation of this single-application philosophy through competitor product developments.
  63. GitLab deploys into multiple clouds from kubectl using CrossplaneThis post details how GitLab is being deployed into multiple clouds using Crossplane, an open-source multicloud control plane. It explains how Crossplane extends the Kubernetes API to manage external managed services (Redis, PostgreSQL, object storage) for production deployments of GitLab. The post outlines the steps for cluster administrators to install Crossplane and provide managed services, and for application owners to provision these services using resource claims and deploy GitLab via the Kubernetes API.
  64. Run a consistent serverless platform with GitLab and KnativeThis post details the integration of GitLab with Google Cloud Run and Knative to enable serverless deployments on Kubernetes. It highlights how GitLab can automatically build and deploy applications/functions as Knative services, provide endpoints, and display load/invocation metrics. The integration simplifies the deployment of Functions-as-a-Service (FaaS) by abstracting infrastructure complexities.
  65. The industry moves toward single DevOps lifecycle applicationsThis post discusses the industry trend towards DevOps consolidation and the increasing demand for products that span a larger part of the DevOps lifecycle. It highlights GitLab's position as a leader in this space, emphasizing its single, integrated application for the entire DevOps lifecycle, from planning to monitoring, and its native support for cloud-native deployments. The post also references an acquisition that validates this market direction.
  66. Why improving continuously speeds up deliveryThis post introduces the concept of continuous improvement and its application to DevOps, drawing parallels from 'The Goal' and 'The Phoenix Project'. It outlines the 'Three Ways' of DevOps (Systems Thinking, Amplify Feedback Loops, Culture of Continual Experimentation and Learning) as principles for increasing operational efficiency and speed. It suggests simplifying scope, empowering teams, and measuring value streams to reduce cycle time. The post advocates for a Kaizen approach to continuous improvement through small, incremental changes to identify and address bottlenecks in the value stream.
  67. Examples of legacy modernisation projectsThis post discusses legacy system modernization as a key challenge for enterprises. It highlights the true cost of legacy systems, including maintenance resources, lost productivity, and security vulnerabilities. The post advocates for application modernization strategies that focus on specific challenges rather than full rip-and-replace. It provides four examples of how teams have modernized applications: leveraging microservices, improving automation, simplifying the toolchain, and reducing lifecycles. These examples illustrate practical approaches to achieving development efficiency and innovation.
  68. Beyond trends: Committing to application modernizationThis post introduces a pragmatic approach to application modernization, emphasizing starting small with cross-functional teams, adopting the Minimally Viable Change (MVC) mindset for smaller, iterative releases, and prioritizing the mastery of Continuous Delivery and Deployment (CD) through automated pipelines. It advocates for a cultural and technological shift towards DevOps to accelerate software delivery while maintaining stability and security.
  69. Crossplane lowers the barrier to a multi-cloud futureThis post details the integration of GitLab with Crossplane, an open-source multi-cloud control plane. Crossplane introduces workload resource abstractions on top of existing managed services and cloud offerings to enable workload portability across cloud providers. GitLab is the first complex application to be deployed using Crossplane, demonstrating its capability to orchestrate clouds and simplify multi-cloud strategies.
  70. GitHub Actions affirms all-in-one is eating the marketplace modelThis post argues that the trend in software development tools is moving from a marketplace model with many disparate point solutions towards an all-in-one integrated platform. It highlights GitHub's launch of GitHub Actions as an example of this trend, competing directly with its own marketplace vendors. The post posits that this shift is driven by the increasing complexity of the technology landscape, the need for speed and simplicity, and the challenges of managing complex toolchains, especially with the rise of microservices and cloud-native architectures. GitLab is presented as a complete DevOps platform delivered as a single application, with integrated CI/CD as a critical first step. The post predicts more acquisitions across the technology landscape as the demand for all-in-one solutions grows.
  71. GitLab's product vision for 2019 and beyondThis post outlines GitLab's product vision for 2019 and beyond, focusing on increasing depth in existing features and expanding breadth across the DevOps lifecycle. It introduces three new capabilities: Value Stream Management (automating issue board progression), Incident Management (centralized incident response with integrated context), and Auto Remediate (automating dependency vulnerability patching and deployment rollbacks).
  72. Better Developer & Customer Experiences with One ApplicationThis post highlights how Charter Communications uses GitLab as a single application for their entire software development lifecycle, reducing their feedback loop from two weeks to minutes. It emphasizes the benefits of a single place for development, operations, and feedback for a great developer experience, and how quick feedback is essential for competitiveness. Key takeaways include the ability to deploy mutually exclusive environments from every branch for immediate feedback, cutting down on manual build machine management.
  73. Auto DevOps will be enabled by default as part of GitLab’s 11.3 releaseThis post announces the default enablement of Auto DevOps in GitLab 11.3, building upon its general availability in 11.0. It introduces a mechanism to automatically disable Auto DevOps if a pipeline fails, notifying project owners. The rollout strategy includes a gradual enablement on GitLab.com before the self-managed release.
  74. GitLab Auto DevOps in actionThis post introduces and demonstrates GitLab Auto DevOps, highlighting its role in automating the entire DevOps lifecycle from code commit to deployment and monitoring. It emphasizes how Auto DevOps integrates testing, security scanning, packaging, and deployment into a single, automated pipeline, enabling faster and more secure software delivery.
  75. GitLab's 2018 Product Vision: Prototype demoThis post outlines GitLab's 2018 product vision, emphasizing the expansion to cover the complete DevOps lifecycle, including Operations and Security as primary user interfaces. It introduces a prototype demonstrating enhanced merge request views with test summaries, artifact links, code quality, security testing (SAST, DAST, dependency scanning), performance analysis, and license policy checks. The vision also includes an Operations health dashboard for monitoring production, cluster resource usage, and automated issue detection and resolution. A Security Audit view is presented for tracking vulnerabilities and automated remediation via merge requests, including automatic deployment and rollback capabilities.
  76. Creating open course environments with GitLab and Grav CMSThis post details how to combine an institutionally hosted instance of GitLab with a modern flat-file CMS like Grav to create open course environments. It highlights the benefits of using GitLab for collaborative editing, version control, and student contribution to course materials, and Grav for its Markdown support and flat-file architecture, which pairs well with Git-based services. The author also shares their experience building a 'CMPT-363 Open Course Hub' using this approach, integrating other open-source tools and the institutional LMS.
  77. Beyond CI/CD: GitLab's DevOps visionThis post outlines GitLab's evolving DevOps vision, moving beyond CI/CD to encompass the entire software development lifecycle, including operations. It details the expansion of CI/CD capabilities to include review apps, deployment tracking, system monitoring (Prometheus), and future plans for business monitoring and load testing. The post introduces the concept of an 'Ops Dashboard' for a holistic view of production environments and service health, and proposes a 'Pipeline view of Environments' to better visualize the relationship between different deployment stages and merge requests. The core message is the integration of development and operations through a unified toolchain.
  78. Auto Deploy a GitLab.com project to Google CloudThis post details the initial implementation and setup of GitLab's Auto Deploy feature, which automates the deployment of applications to Kubernetes. It explains the core functionality of Auto Deploy, its integration with CI/CD pipelines, and the process of packaging applications into Docker images. The post also outlines the steps required to tie GitLab Auto Deploy with Google Kubernetes Engine (GKE), including project setup, cluster creation, credential configuration, and applying the auto deploy template to `.gitlab-ci.yml`. It highlights the benefits of automated deployment for new commits and manual deployment to production.
  79. From 2/3 of Git market to next-Gen CI system & auto DevOpsThis post announces the future direction of GitLab, focusing on Auto DevOps as a concept to fully automate the DevOps lifecycle. It highlights GitLab's existing strengths in self-managed Git market share and its position as a popular next-generation CI system. The post introduces Auto Deploy as an evolution and presents a vision for Auto DevOps, including Auto Create, Auto Build, Auto CI, Auto Deploy, Auto Code Quality, and Auto Review Apps, aiming to deliver more from idea to production with out-of-the-box functionality.
  80. GitLab was at VueConf 2017!This post details the integration of Vue.js into GitLab's stack, moving from CoffeeScript to EcmaScript 6, and outlines a specific architecture for building small Vue applications with a focus on state management using a service and store pattern. It also discusses strategies for handling complex cases where full Vue.js rewrites are not feasible, employing a mediator pattern to share state and avoid duplicate network calls.
  81. Demo - Auto Deploy from GitLab to an OpenShift container clusterThis post demonstrates how to build, test, and deploy a basic application in a container from GitLab to an OpenShift container cluster using GitLab's built-in CI/CD and its integration with OpenShift. It explains the concept of containers and their benefits for DevOps at scale, including consistency across environments and faster code shipping.
  82. Demo: cloud native development with GitLabThis post demonstrates the practical application of cloud-native development principles using GitLab. It showcases a workflow that includes installing GitLab on Kubernetes, building a project, creating review apps, utilizing a container registry for Docker images, deploying to production on Kubernetes, and monitoring with Prometheus, all within a short timeframe.
  83. Complete, but never finished/:/ Review AppsIntroduced the Review Apps feature, which creates ephemeral environments for each topic branch. The initial release in 8.12 provided basic name and URL configuration. Subsequent releases added the ability to stop/delete apps and automatically remove them when a branch is merged and deleted, based on user feedback.
  84. Our big Frontend plan revealedThis post details GitLab's frontend evolution plan, focusing on the strategic adoption of Vue.js and webpack. It outlines a phased approach to rewriting parts of the frontend in Vue, prioritizing new features and areas with significant performance gains, rather than a complete rewrite. The integration of webpack is highlighted for its benefits in dependency management, code bundling (including tree shaking and code splitting), hot module replacement for faster development, and improved SVG handling. The removal of Turbolinks is also discussed as a means to improve page load performance and simplify event management, enabling better JavaScript organization and the potential for pages to become independent Vue applications.
  85. Behind the scenes: How we built Review AppsThis post details the iterative development and release of the Review Apps feature across GitLab versions 8.12, 8.13, and 8.14. Key technical contributions include: 1. In 8.12: Allowing specification of environment URLs directly in `.gitlab-ci.yml` and enabling the use of variables within environment names and URLs, enabling dynamic environments. 2. In 8.13: Reusing manual actions to script app deletion/stopping and introducing a new keyword to identify stop jobs, with a corresponding UI change to a stop button. 3. In 8.14: Automatic detection and execution of the stop job when a branch is deleted, and the introduction of a convention for grouping environments into folders based on naming prefixes to manage the environments list.
  86. 'GitLab is a slam dunk': One team lead weighs his optionsThis post details a team lead's positive experience and strong recommendation for GitLab, highlighting its integrated nature (version control, bug tracking, CI/CD) and suitability for distributed teams. It emphasizes the benefits of self-hosting and open-source for professional developers and discusses the challenges of training users accustomed to older workflows (e.g., Subversion to Git migration). The author also notes the growing community and pace of innovation within GitLab.
  87. Introducing Review AppsIntroduced Review Apps, a feature that dynamically creates ephemeral environments for each branch, automating deployment and deletion. This allows for testing and demoing individual merge requests without manual intervention, improving the review process for developers, product managers, QA, and designers. The post details the benefits of Review Apps in solving problems related to multi-stage testing, issue attribution, and UX testing, and provides a basic `.gitlab-ci.yml` example for implementation.
  88. Continuous Delivery with GitLab and ConvoxThis post details the integration of GitLab with Convox for Continuous Delivery (CD). It explains how to set up a Convox deployment environment on AWS, authorize Convox with GitLab and Slack, and leverage GitLab webhooks and deploy keys to automate builds, tests, and deployments. It also provides an example of a `.gitlab-ci.yml` file for integrating automated testing with Convox deployments.
  89. An inside look at the infrastructure of GitLab.comThis post details the specific server counts and infrastructure components used by GitLab.com in April 2016. It breaks down the infrastructure into directly managed servers (HAProxy load balancers, application stack workers, NFS, Redis, PostgreSQL, Elasticsearch) and Azure-managed resources (Availability Sets for HA). It also quantifies the number of autoscaled Docker machines used for shared runners, providing a range of total server utilization.
  90. The hardware that powers 100,000 git repositoriesThis post details the initial migration of GitLab.com from AWS to self-hosted hardware to address cost and CPU-bound scaling limitations. It describes the hardware used (HP DL180 G6 servers with dual X5690 CPUs, 32GB RAM, and 12x 2TB HDDs in RAID 10) and the implementation of DRBD for failover. It also outlines the future plan to return to AWS for easier horizontal scaling and the availability of larger EBS volumes.
  91. GitLab.com now runs GitLab Enterprise EditionGitLab.com is now running GitLab Enterprise Edition (EE). This allows users to experience all GitLab features and enables GitLab to run EE at scale, monitoring performance regressions and other issues on their own servers. They also run a daily updated instance of Community Edition for employees to quickly discover breaking changes.