GitLab today took the wraps off a major update to its continuous integration/continuous delivery (CI/CD) platform that embeds analytics tools in workflows to identify the root cause of inefficiencies, among other additional capabilities.

David DeSanto, senior director for product management at GitLab, said that capability is part of an ongoing effort to include value stream analytics within the core GitLab 14 platform as an alternative to acquiring and deploying a separate platform. There are also additional charts and dashboards that enable DevOps teams to uncover bottlenecks over time.

In addition, GitLab announced it is extending the security capabilities of the platform by adding integrations with open source Semgrep and Trivy vulnerability scanning tools as part of an effort to enable organizations to embrace DevSecOps best practices within workflows. GitLab has also added support for the fuzz testing tool it gained via the acquisitions of Fuzzit and Peach Tech to enable DevOps teams to test application security more thoroughly along with making available additional dashboards to track security metrics.

As part of an effort to enable organizations to better secure their software supply chains, GitLab has also added support for immutable pipeline definitions that can’t be altered without specific levels of permissions being granted. That capability also enables DevOps teams to more easily achieve compliance with any number of regulatory frameworks, noted DeSanto.

The company is also adding a pipeline editor that provides access to a visual tool for creating, managing and visualizing pipelines. That tool is designed to both make DevOps more accessible to novices and provide experienced DevOps teams with an alternative tool for managing pipelines in a way that doesn’t require them to write additional code.

Finally, as part of its comprehensive approach to DevOps, GitLab is also making available agent software for Kubernetes clusters to eliminate the need for organizations to acquire a separate DevOps platform to build and deploy cloud-native applications based on microservices constructed using containers. The company now provides IT organizations with the option of crafting a GitOps workflow for Kubernetes using either an agentless or agent-based approach.

Gitlab is betting that, as DevOps continues to evolve and mature, more organizations will prefer to replace the various tools they need to integrate themselves with a platform that lowers the total cost of DevOps. Gartner is forecasting that, by 2023, 40% of organizations will have switched from multiple point solutions to a DevOps value stream delivery platform to streamline application delivery, versus less than 10% using such a platform in 2020. Today, only 10% of organizations are employing such a platform, according to Gartner.

There should also be many more organizations employing DevOps workflows to build applications. Organizations of all sizes now realize how dependent they are on software to drive a wide range of digital business transformation initiatives. The rate at which that software can now be securely developed and updated, in many cases, goes to the heart of their ability to compete. The issue is finding a way to achieve that goal without constructing a platform that ultimately takes time and resources away from building secure software.

What Is DevOps?

DevOps is a cultural and organisational movement — a combination of practices, ideas, tools, and processes designed to break down the traditional silos between software development and IT operations teams. Its core goal is to enable organisations to build, test, and release software faster, more reliably, and with higher quality.

In Patrick Debois’s own framing, DevOps represents “a movement of people who think it’s time for a change in the IT industry — time to stop wasting money, time to start delivering great software, and building systems that scale and last.”

Key attributes of a DevOps culture include:

• Shared ownership — development and operations teams are jointly responsible for product quality and uptime.
• Continuous feedback loops — teams monitor production systems and feed insights back into the development process.
• Automation-first thinking — repetitive manual tasks (provisioning, testing, deployment) are automated wherever practical.
• Incremental delivery — software is shipped in small, frequent batches rather than large, infrequent releases.
• Collaborative tooling — teams share dashboards, on-call rotations, and post-mortems instead of working in isolation.

DevOps is not a specific tool, a job title, or a pipeline. It is a way of working — a cultural shift that must be adopted at the team and organisational level before any tooling decisions are made.

Why DevOps Exists: The Historical Context

Historically, development teams wrote code and then “threw it over the wall” to operations teams who were responsible for deploying and running it. This handoff model created conflict, slow feedback, finger-pointing during outages, and long release cycles. DevOps emerged as a direct response to these friction points, encouraging the two groups to collaborate throughout the entire software lifecycle rather than only at handoff moments.

DevOps in Practice: A Real-World Example

Facebook is a widely cited example of DevOps practices at scale. Its engineering approach has long emphasised code ownership, automation, incremental changes, and continuous improvement — all hallmarks of DevOps thinking. The company reportedly completed a migration of its infrastructure and back-end services to the Chef configuration management platform around 2015, allowing it to manage thousands of servers and push multiple code updates daily. Some of those Chef cookbooks were also made publicly available.

This example illustrates that DevOps is not a single tool or pipeline — it is a philosophy that shapes how an entire engineering organisation operates.

What Is CI/CD?

CI/CD stands for Continuous Integration / Continuous Delivery (and sometimes Continuous Deployment). It is a concrete set of engineering practices and automated workflows — often implemented as a “pipeline” — that enable teams to integrate, test, and release code changes frequently and reliably.

Where DevOps is the culture, CI/CD is one of the most important technical implementations of that culture. Think of DevOps as the philosophy and CI/CD as a key part of the machinery that puts that philosophy into practice.

Continuous Integration (CI)

Continuous Integration is the practice of developers merging their code changes into a shared repository frequently — ideally multiple times per day. Each merge triggers an automated build and a suite of automated tests. The goals are:

• Catch integration bugs early, before they compound.
• Keep the main branch in a consistently deployable state.
• Give developers rapid feedback on whether their change broke anything.

In their book Continuous Delivery, Jez Humble and David Farley recommend that developers check in to the main branch at least a couple of times a day. The longer a branch lives in isolation, the harder — and riskier — the eventual merge becomes.

Continuous Delivery (CD)

Continuous Delivery extends CI by ensuring that every change that passes automated tests is also automatically prepared for release to production. Critically, the final push to production still requires a human decision. A staging or pre-production environment is typically used for user acceptance testing (UAT) or manual review before deployment is approved.

The key benefit of Continuous Delivery is that releases become low-risk, routine events rather than high-stakes, infrequent ordeals. Because the software is always in a releasable state, the business can choose when to ship based on business needs rather than technical readiness.

Continuous Deployment (also CD)

Continuous Deployment goes one step further: every change that passes all automated test stages is automatically pushed to production without any manual approval step. This requires a high level of confidence in the automated test suite, because there is no human gate before the change reaches users.

Continuous Deployment is not appropriate for every organisation or every product. Regulated industries, for example, may require manual sign-off before production releases. However, for mature teams with comprehensive test coverage, it can dramatically accelerate the feedback loop between developers and end users.

Summary: The Scope of Automation in Each Practice

CI/CD in Practice: A Real-World Example

The ReactJS framework maintained by Facebook (now Meta) is a publicly visible example of CI/CD in action. The project’s GitHub repository includes status badges — such as CircleCI build status and code coverage reports via Coveralls — that reflect the results of their automated pipeline on every pull request. Clicking through those badges shows the individual steps of their CI process and how the pipeline is configured. This transparency also serves as a useful learning resource for teams building their own pipelines.

CI/CD vs. DevOps: The Core Distinction

The confusion between CI/CD and DevOps is understandable — both aim to speed up and improve software delivery, and CI/CD is almost always present in a healthy DevOps organisation. But they operate at different levels:

• DevOps is the culture and strategy. It defines how teams are structured, how they communicate, and what values guide their work. You cannot buy DevOps as a product or install it as a tool.
• CI/CD is a set of technical practices and automated pipelines. It is one of the most powerful enablers of a DevOps culture, but it is possible to run a CI/CD pipeline without having a genuine DevOps culture — and conversely, a DevOps culture encompasses much more than just CI/CD (including monitoring, incident management, infrastructure as code, and organisational design).

A useful analogy: DevOps is to CI/CD what Agile is to Scrum. Agile is a set of values and principles; Scrum is a specific framework that implements many of those principles. Similarly, DevOps is the broader cultural philosophy, and CI/CD is one of the most important concrete frameworks for living it out.

Why the Distinction Matters

Getting this distinction right has practical consequences:

• Tooling decisions: Choosing a CI/CD tool (Jenkins, GitHub Actions, GitLab CI, CircleCI, etc.) is a technical decision. Adopting DevOps requires leadership buy-in, team restructuring, and cultural change — no tool alone delivers it.
• Diagnosing problems: If your deployments are still slow and painful despite having a CI/CD pipeline, the root cause may be cultural — siloed teams, poor communication, lack of shared ownership — not a pipeline configuration problem.
• Setting expectations: Promising stakeholders that “we’re adopting DevOps” when you mean “we’re setting up a Jenkins pipeline” sets up a gap between expectation and reality that can undermine confidence in the initiative.

Key Takeaways

• DevOps is a cultural and organisational philosophy that bridges the gap between development and operations to enable faster, higher-quality software delivery.
• CI/CD is a set of engineering practices and automated pipelines — Continuous Integration, Continuous Delivery, and Continuous Deployment — that automate the building, testing, and releasing of software.
• CI/CD is one of the most important technical pillars of a DevOps culture, but the two terms are not synonymous.
• You can implement CI/CD without a full DevOps transformation, but you cannot achieve a true DevOps culture without some form of CI/CD automation.
• The key differentiator among CI, Continuous Delivery, and Continuous Deployment is the degree of automation applied — particularly whether the final production deployment requires human approval.

Prerequisites

• Visual Studio Code — available for Windows, macOS, and Linux from code.visualstudio.com.
• Team Foundation Server (TF) command-line client — included with Visual Studio 2017/2019 or available as a standalone download. Note the path to tf.exe after installation; you will need it when configuring the extension.
• An active Azure DevOps organisation and project with at least one repository.

Setting Up the Environment

Installing Visual Studio Code

Download the VS Code installer for your platform and run it. The Windows installer wizard presents the following steps:

1. License Agreement — Accept the terms and click Next.
2. Select Destination Location — The default path (C:\Program Files\Microsoft VS Code) is fine for most installations. Click Next.
3. Select Start Menu Folder — Leave the default and click Next.
4. Select Additional Tasks — Enable all optional tasks (such as adding VS Code to the PATH and registering it as the default editor for supported file types). These options make it easier to open files directly from Windows Explorer. Click Next.
5. Ready to Install — Review your choices and click Install.
6. Finish — Click Finish; VS Code launches automatically.

On macOS or Linux, extract the downloaded archive or use your package manager and launch the application from your Applications folder or terminal.

Understanding the VS Code Interface

The VS Code interface has several key areas worth knowing before you install extensions:

• Activity Bar (far left) — Icons for Explorer, Search, Source Control, Run & Debug, and Extensions. Installed extensions can add their own icons here.
• Side Panel — Opens when you click an Activity Bar icon, showing the relevant tree view or tool panel.
• Editor Area (centre) — Where files open for editing.
• Status Bar (bottom) — Shows contextual information such as the active Git branch, line/column number, and extension status indicators.
• Panel (bottom, toggled with Ctrl+`) — Hosts the integrated terminal, Problems, Output, and Debug Console tabs.

The Command Palette (F1 or Ctrl+Shift+P) is one of the most productive features in VS Code. It gives you instant keyboard-driven access to every editor command, extension action, and setting. Get into the habit of using it rather than hunting through menus.

Locating tf.exe

The tf.exe command-line client bridges VS Code’s Azure Repos extension and the TFVC (Team Foundation Version Control) protocol. If you have Visual Studio 2017 installed, the executable is typically found at:

C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer\tf.exe

The exact path varies depending on your Visual Studio edition (Enterprise, Professional, Community) and version. Copy the full path; you will paste it into a VS Code setting in the next section.

Note: If your repository uses Git rather than TFVC, you do not need tf.exe. Git is built into VS Code and into Azure DevOps by default. The tf.exe path is only required for TFVC workspaces.

Enabling Integration with Azure DevOps

Installing the Azure Repos Extension

VS Code does not include Azure DevOps integration out of the box. You add it through the Extensions Marketplace:

1. Click the Extensions icon in the Activity Bar, or press Ctrl+Shift+X.
2. In the search box, type Azure Repos.
3. Select the Azure Repos extension published by Microsoft from the results list.
4. Click Install.

After installation, the extension adds Azure DevOps–related commands to the Command Palette. You can verify this by opening the palette (F1) and typing Team to see the available commands.

Configuring the TFVC Path (TFVC Repos Only)

If your Azure DevOps project uses TFVC, point the extension to the tf.exe binary you located earlier:

1. Click the Manage gear icon in the lower-left corner of VS Code and select Settings (or press Ctrl+,).
2. In the Settings search box, type tfvc.location.
3. Paste the full path to tf.exe into the Tfvc: Location field.

Settings are saved automatically; no manual save step is required.

Synchronising Your First Repository

Cloning the Repository

1. Open your Azure DevOps project in a browser and navigate to Repos.
2. Click the Clone button to open the clone dialog.
3. Select Clone in VS Code from the IDE options.
4. VS Code opens and displays a confirmation dialog asking permission to handle the Azure DevOps URL. Click Open.
5. A folder-picker dialog appears. Choose the local directory where you want the repository to be cloned, then click Select Repository Location.
6. VS Code clones the repository and displays a notification when the process is complete. Click Open in the notification to open the cloned folder.

All files and folders from the remote repository are now visible in the VS Code Explorer panel on the left.

Signing In to Azure DevOps

Before you can push changes, authenticate with Azure DevOps from within VS Code:

1. Open the Command Palette (F1) and type Team: Signin, then press Enter.
2. Choose your preferred authentication method:
   • Provide an access token manually — Generate a Personal Access Token (PAT) in Azure DevOps under User Settings → Personal Access Tokens and paste it when prompted.
   • Authenticate automatically — The extension generates a device code, opens a browser window, and asks you to enter the code and sign in with your Azure AD credentials.
3. Follow the prompts to complete authentication.

Once authenticated, the Status Bar at the bottom of VS Code displays your Azure DevOps connection status.

Making, Committing, and Pushing Changes

1. Open any file in the repository (for example, README.md), make a change, and save (Ctrl+S).
2. Click the Source Control icon in the Activity Bar (or press Ctrl+Shift+G). The modified file appears in the Changes list.
3. Click the ✓ (checkmark) icon at the top of the Source Control panel to commit. VS Code may ask you to stage all changes first — confirm if prompted.
4. Enter a meaningful commit message in the Command Palette prompt and press Enter.
5. To push the commit to Azure DevOps, click the sync indicator in the Status Bar (it shows an upload/download arrow with a count of pending changes) or open the Command Palette and run Git: Push.

After the sync completes, open the repository in Azure DevOps in your browser and confirm that your commit appears in the repository history.

Key Takeaways

• Visual Studio Code is a free, cross-platform editor that works on Windows, macOS, and Linux.
• The Azure Repos extension (published by Microsoft) adds Azure DevOps integration directly to the editor.
• TFVC users need to configure the tfvc.location setting to point at the tf.exe binary. Git-based repos work with VS Code’s built-in Git support and do not require this step.
• The Command Palette (F1) is the fastest way to run any editor or extension command.
• Authentication can be handled via a Personal Access Token or an interactive device-code flow tied to your Azure AD account.

Once your environment is configured, VS Code becomes a capable, lightweight workstation for managing infrastructure-as-code, reviewing pull requests (via the Azure DevOps pull request extension), and running pipelines — all without leaving your editor.

What Is Percy?

Percy is a visual testing tool that integrates into your CI/CD pipeline to capture screenshots of your application, track visual changes between builds, and require explicit team approval before visual regressions are accepted. When combined with Codeship Pro and Docker, Percy lets you automate visual regression detection as a first-class step in your delivery workflow.

Setting Up Percy with Codeship Pro

The integration relies on two components working together: Percy’s SDK (which varies by project type) installed inside your Docker image, and Percy’s API credentials passed in as encrypted environment variables in Codeship Pro.

Setting Your Percy Environment Variables

When you create a new project inside Percy, the platform provides two credential values:

• PERCY_TOKEN — the API token that authenticates your builds with Percy.
• PERCY_PROJECT — the unique identifier for your Percy project.

Both values must be added as encrypted environment variables in your codeship-services.yml file. Codeship Pro’s encrypted environment variable support ensures these secrets are never stored in plain text in your repository. Refer to the Codeship Pro environment variables documentation for instructions on encrypting and referencing these values.

Integration by Project Type

Static Sites

For static HTML sites running inside Docker images on Codeship Pro, Percy provides a CLI tool distributed as a Ruby gem. Install it in your Dockerfile:

RUN gem install percy-cli

Prerequisite: Your Docker image must include both Ruby and RubyGems. Without them, the gem installation step will fail.

Once the gem is installed, add a Percy snapshot step to your codeship-steps.yml file:

- service: your_service
  command: percy snapshot directory_to_snapshot

A few important details about this command:

• Replace your_service with the name of the service defined in your codeship-services.yml.
• Replace directory_to_snapshot with the path to the directory containing your built static files.
• The target directory must contain HTML files — Percy uses them to render the snapshots.
• You can add multiple snapshot steps to cover multiple directories in one build.

Ruby Projects

For Ruby applications using Capybara, Minitest, RSpec, or similar test frameworks, Percy provides the percy-capybara gem. Add it to your Dockerfile:

RUN gem install percy-capybara

Alternatively, add percy-capybara to your Gemfile and let Bundler manage the dependency — this is typically the cleaner approach for Ruby projects.

Prerequisite: As with static sites, your Docker image must include both Ruby and RubyGems.

After installation, you need to add Percy hooks directly into your test specs. The specific integration code — such as calling Percy::Capybara.snapshot within your tests — is documented in detail in the Percy documentation for each supported test framework. Your test suite is then invoked via the standard command step in codeship-steps.yml, and Percy captures snapshots automatically as tests run.

Ember Projects

For Ember.js applications, Percy provides a dedicated Ember addon. Install it inside your Docker image by adding the following to your Dockerfile:

RUN ember install ember-percy

As with the Ruby integration, you will need to add Percy hooks to your Ember test specs. Consult the Percy documentation for the specific API calls required to trigger snapshots within your Ember tests. Your test suite is then invoked via your codeship-steps.yml file as a normal build step, and Percy captures visual snapshots during the test run.

How the Full Pipeline Fits Together

Regardless of project type, the overall integration pattern in Codeship Pro is consistent:

1. Build your Docker image with the appropriate Percy SDK installed.
2. Encrypt your Percy credentials (PERCY_TOKEN and PERCY_PROJECT) and reference them in codeship-services.yml.
3. Run your tests or snapshot command as a step in codeship-steps.yml.
4. Review visual diffs in the Percy dashboard, where your team can approve or reject detected changes before the build is considered passing.

This workflow ensures that visual regressions are caught automatically in CI, and that no unreviewed UI change can silently reach production.

Further Reading

• Percy documentation — SDK setup guides for all supported frameworks.
• Codeship Pro documentation — reference for codeship-services.yml and codeship-steps.yml.