Cat On A Spreadsheet

Automating Build Pipelines for VBA Projects (CI/CD Concepts for Excel)

Once VBA projects reach a certain level of maturity, the biggest risk is no longer logic bugs or performance issues. The real risk becomes how code moves. Who changed it, how it was deployed, and whether what’s running in production actually matches what was approved. This is the same problem that every other software platform solved years ago with build pipelines. Excel and VBA are not exempt from this reality — they are simply late to it.

A build pipeline for VBA does not need cloud services, YAML files, or DevOps teams. What it does need is discipline, repeatability, and a clear separation between source, build, and deployment. Once those concepts are in place, Excel solutions become predictable, auditable, and far easier to maintain.

This post explains how to design a practical build pipeline for VBA projects that fits naturally into a corporate Excel environment.

What a “Build” Means in VBA Terms

In traditional software, a build produces a compiled artifact. In VBA, the equivalent artifact is a macro-enabled workbook or add-in that contains a specific version of code.

The critical shift is understanding that the workbook itself is not the source of truth. The source of truth is the exported VBA code — the .bas, .cls, and .frm files stored under version control. A build is the act of taking that source and injecting it into a clean Excel container in a deterministic way. If you cannot rebuild your production workbook from source on demand, you do not have a build process — you have hope.

The Core Pipeline Concept

A minimal VBA build pipeline follows a simple flow. Code is edited in a development workbook, exported automatically into a source directory, committed to version control, and tagged with a version. A clean workbook is then opened, all modules are imported from source, metadata is stamped into the file, and the workbook is saved as a release artifact. This can be done manually at first, but the real power appears when the entire process becomes scripted and repeatable.

Exporting Code as a Build Step

Exporting code is not a convenience step. It is the build input. The export routine must run cleanly, consistently, and without developer intervention. If exporting modules requires manual clicks, your pipeline is already broken.

A robust export routine looks like this:

  Public Sub ExportAllModules()
 
      Dim comp As Object
 
      Dim exportPath As String
 
      exportPath = ThisWorkbook.Path & "\src\"
 
      If Dir(exportPath, vbDirectory) = "" Then MkDir exportPath
 
      For Each comp In ThisWorkbook.VBProject.VBComponents
 
          Select Case comp.Type
 
              Case 1
 
              comp.Export exportPath & comp.Name & ".bas"
 
              Case 2
 
              comp.Export exportPath & comp.Name & ".cls"
 
              Case 3
 
              comp.Export exportPath & comp.Name & ".frm"
 
          End Select
 
      Next comp
 
 End Sub

This folder becomes the input for every downstream step. If it is wrong, the build is wrong.

Stamping Build Metadata

Every build should identify itself clearly. This is not optional. A production workbook must be able to answer three questions instantly: when it was built, which version it is, and which source commit produced it. Without this information, support becomes guesswork.

A simple approach is to stamp metadata into hidden named ranges during the build:

  Public Sub StampBuildInfo(Version As String)
 
      With ThisWorkbook
 
          .Names.Add "AppVersion", "=""" & Version & """"
 
          .Names.Add "BuildTimestamp", "=""" & Now & """"
 
      End With
 
 End Sub

When a user reports an issue, you should never have to ask which file they’re using. The workbook should already know.

Rebuilding From Source

A build should never modify an existing production file. It should start from a clean shell workbook.

The import process removes any ambiguity about what code is included:

  Public Sub ImportModulesFromSource()
 
      Dim file As String
 
      Dim srcPath As String
 
      srcPath = ThisWorkbook.Path & "\src\"
 
      file = Dir(srcPath & "*.*")
 
      Do While file <> ""
 
          ThisWorkbook.VBProject.VBComponents.Import srcPath & file
 
          file = Dir
 
      Loop
 
 End Sub

This is where the build either succeeds or fails. There is no “mostly correct” state.

Driving Excel From Outside Excel

True pipelines remove humans from the loop. Excel can be launched headlessly via command line, PowerShell, or scheduled tasks. A controlling script opens Excel, runs the build macro, saves the output workbook, and closes Excel cleanly. At that point, Excel becomes just another build engine — not the environment where decisions are made. This is the moment when VBA stops being fragile.

Why This Changes Everything

With a pipeline in place, promotions between environments become boring. That is a compliment.

You stop copying files. You stop wondering whether the right version was deployed. You stop fixing bugs that already existed two releases ago. Instead, every workbook in circulation is traceable to a specific build, created from known source, at a known time.

Most importantly, you gain confidence. Confidence to refactor, confidence to scale, and confidence that Excel — often dismissed as “just a spreadsheet” — can behave like a real production platform.