The Golden Standard: Automating SAS Viya Formats with CI/CD

Welcome to the final chapter of our deep dive into SAS Viya formats.

In Part 1, we exposed the “architectural dichotomy” that causes formats to vanish between the Compute Server and CAS. In Part 2, we gave you the tactical tools (PROC CPORT, FMTC2ITM, and the CLI) to migrate your legacy catalogs.

Now, we face the most critical question: How do you keep it all in sync?

If you have a developer manually running PROC FORMAT on the Compute Server on Monday, and an administrator manually importing a CSV into CAS on Tuesday, you have already failed. You have reintroduced the “split-brain” risk we fought so hard to eliminate.

To truly master SAS Viya, you must stop treating formats as files and start treating them as code.

The New Rule: Code is Truth

In a modern analytics environment, the “Single Source of Truth” cannot be a binary file sitting on a disk. It must be version-controlled source code stored in a repository like Git.

This is the Golden Standard:

1. No GUI Edits: Manually creating formats in SAS Environment Manager is strictly forbidden for production assets.
2. No Ad-Hoc Runs: Developers do not “run” format code in production.
3. Automated Deployment: A pipeline handles the synchronisation.

The Strategy: Synchronised Dual-Target Deployment

The industry best practice for SAS Viya is a workflow we call Synchronised Dual-Target Deployment.

Instead of migrating from Compute to CAS, or vice versa, you deploy to both simultaneously. This ensures that whether a user is running a legacy batch job or building a cutting-edge Visual Analytics dashboard, they are seeing the exact same data definitions.

The Architecture in Action

Here is what a modern SAS Viya format pipeline looks like:

Step 1: The Trigger

A data steward updates a master format definition (e.g., a SAS program or a CSV file) and pushes the change to a Git repository (e.g., GitLab, GitHub, Bitbucket).

Step 2: The CI/CD Pipeline

The commit triggers an automated job (Jenkins or GitLab Runner). This runner has access to the SAS Viya environment via the CLI and batch interfaces.

Step 3: Target A – The Compute Layer

The pipeline executes a batch SAS session. It compiles the formats and updates the persistent .sas7bcat catalogs residing on the shared storage.

• Result: All SAS Studio and batch jobs are updated.

Step 4: Target B – The CAS Layer

The pipeline executes a sas-viya CLI command (or a Python SWAT script). It drops the old global format library from memory and reloads it from the fresh source.

• Result: All Visual Analytics reports are updated.

The “Drop and Swap” Technique

Updating a global format library in CAS while users are active requires finesse. You cannot simply overwrite a library that is in use.

To avoid disruption, your pipeline should implement a “Drop and Swap” logic:

1. Load the new formats into a temporary library (e.g., HR_Formats_New).
2. Promote it to Global Scope.
3. Update the CAS search order to prioritize HR_Formats_New.
4. Drop the old HR_Formats library.

The Permstore: Forget the Startup Script

Veterans of SAS Viya 3.x might remember the pain of writing Lua startup scripts to reload formats after each server reboot.

In SAS Viya 4, this is solved by the Permstore. When you promote a format library using the CLI or Environment Manager, Viya automatically writes a reference to this persistent store. If the CAS server restarts, it reads the Permstore and automatically rehydrates your global formats.

This “Zero-Touch” persistence means your automated pipeline only needs to run when data changes, not when the server restarts.

Conclusion

The transition to SAS Viya is more than a software upgrade; it is an opportunity to mature your operational processes.

By moving from manual file management to a Synchronised Dual-Target Deployment, you permanently solve the “split-brain” problem. You gain auditability (via Git), stability (via CI/CD), and speed (via CAS).

Your formats are no longer just metadata; they are a managed asset.