Hello and welcome back to the Advent of SysML v2 – a daily, hands-on mini-course designed to bring you up to speed with the new SysML v2 standard and the modern Syside tooling that makes you productive from day one.

By the end of this lesson, you will:

• Understand what CI/CD is and why it matters for SysML v2
• Automate model validation to catch errors on every commit
• Generate reports that update automatically

If you want to dive deeper into the world of SysML v2, check out The SysML v2 Book, where these topics are discussed in more detail.

What is CI/CD?

When your model changes, you need to validate it, regenerate reports, and update documentation. With multiple engineers, frequent changes, and tight schedules, manual processes become bottlenecks. Something gets missed, deliverables drift out of sync, or validation happens too late. Enter CI/CD.

CI/CD stands for Continuous Integration and Continuous Deployment. It’s a practice from software development that automates quality checks and deliverable generation on every change.

Think of it like a quality control system on a manufacturing line: every change gets automatically inspected, verified, and processed before moving forward.

In traditional systems engineering workflows, model changes trigger a cascade of manual tasks: validate the updated model, regenerate the bill of materials (BOM), update interface diagrams, notify stakeholders, ensure consistency across deliverables, etc.

These tasks are straightforward individually, but manual execution doesn’t scale. CI/CD helps us automate the entire workflow. Every time you commit a model change:

• Continuous Integration: The model is validated automatically (syntax, semantics, constraints)
• Continuous Deployment: Reports are regenerated, documentation is updated, and deliverables are published

The system monitors your repository and executes these steps automatically. Commit your change, and within seconds you have validation results and updated reports.

A pipeline is the sequence of automated steps that run on every change. Each step executes in order, and if any step fails, the pipeline stops immediately. Think: validate → generate reports → publish.

Why CI/CD Works With SysML v2

This automation is possible because SysML v2 is fundamentally different from traditional modeling languages:

• SysML v2 is textual. Your models are text files, not binary blobs. This means they can be version-controlled (you learned this in lesson 6), automatically processed, and programmatically analyzed.
• SysML v2 is executable. With Syside Automator, you can evaluate expressions, traverse model structure, extract documentation, and generate reports programmatically. Your models contain computable information, not just diagrams.

Combined with Git for version control and Sysand for package management, CI/CD completes your systems-as-code infrastructure. You’re not just modeling systems – you’re treating models as first-class engineering artifacts with the same automation and quality practices that transformed software development.

Building an Automation Pipeline

Today, we’re building a CI/CD workflow for Santa’s sleigh model with three automated steps:

1. Validate – Check model syntax and semantics
2. Generate – Extract data and create stakeholder reports
3. Publish – Make updated documentation available

These steps run sequentially in the pipeline. If validation fails, the pipeline stops immediately – no point generating reports from a broken model. Let’s look at each step.

Model Validation

Before any reports can be generated or any model can be trusted, it needs to be validated. Syside Automator provides model validation through check function:

The <path> can be either a specific model file or a directory:

This command checks for:

• Syntax errors (malformed SysML v2 text)
• Semantic errors (undefined references, type mismatches)
• Constraint violations (if defined in your model)

In a CI/CD pipeline, you typically use python -m syside check . to validate all models in the repository at once. If any model doesn’t validate, the pipeline fails fast. No need to attempt report generation on broken models.

Report Generation

Different stakeholders need different views of the same model. The Chief Elf Engineer needs budget summaries. The Reindeer Stable Manager needs team rosters. The Logistics Department needs cargo manifests.

Keeping these reports manually synchronized with the model is tedious and error-prone. CI/CD solves this by regenerating all reports automatically from the source model.

Our automation generates a detailed BOM report that includes:

• Executive Summary: System-level metrics (total gifts, cargo & sleigh weight, safety margins, flight mode)
• Reindeer Team Roster: Individual reindeer with descriptions and attributes (weight, power, energy level)
• Sleigh Composition: System components with descriptions
• Cargo Summary: Totals per delivery route (gift count and weight per bag)
• Cargo Breakdown: Individual gifts by route with specific weights

Just like how we extracted values and calculated rollups in lesson 16, the automation script uses Syside Automator to extract this data from the model and format it as markdown and HTML. The code is available in Syside Cloud, but we won’t dive into the implementation details here. The key point is that all data comes directly from the model. So when the model changes, the report updates automatically.

The script traverses the model structure to extract:

• Bilingual documentation (English and French descriptions)
• Calculated attributes (total weights, safety margins, flight mode)
• System composition (reindeer team, sleigh parts, cargo breakdown)
• Individual element properties (weights, power outputs, energy levels)

When the model changes, the report regenerates automatically on the next commit. Stakeholders always see current documentation, manual synchronization is eliminated, and the model remains the single source of truth.

Publishing Reports

The final step is making reports accessible to stakeholders. The pipeline automatically deploys generated reports to GitHub Pages – a static site hosting service that turns repository files into a public website.

Stakeholders get a stable URL (like https://your-org.github.io/your-repo/) that always shows the latest validated reports. The deployment only occurs if validation and generation succeed; failed pipelines never publish broken reports.

The CI/CD Workflow

Here’s how it all comes together in practice:

The pipeline executes on every commit. Engineers get immediate validation feedback. Stakeholders receive updated deliverables. Quality checks run consistently on every change.

Understanding the CI Configuration

The automation is configured in a YAML file that defines when to run, where to run, and what to do. For GitHub, this is .github/workflows/ci.yml. For GitLab, it’s .gitlab-ci.yml. The concepts are the same across all CI platforms.

Here’s what a typical configuration looks like, broken down conceptually:

When to run:

Triggers the pipeline automatically whenever someone commits changes or opens a merge request.

What environment to use:

Spins up a fresh Linux machine. This ensures reproducible results – every run starts from the same clean state.

What steps to execute:

Each step runs in order. If any step fails (returns a non-zero exit code), the pipeline stops immediately and marks the run as failed. You get notified, and no reports are generated from broken models.

Cross-platform concepts:

These concepts work the same whether you use GitHub Actions, GitLab CI, Jenkins, Azure DevOps, or any other CI platform:

• Triggers: When does it run? (on push, on merge request, on schedule, manually)
• Environment: Where does it run? (Linux, Windows, what dependencies to install)
• Steps: What does it do? (checkout code, validate, generate, publish)
• Artifacts: What does it produce? (reports, logs, generated files)
• Failure handling: What happens when something breaks? (stop immediately, notify, retry)

The configuration syntax varies slightly between platforms, but the underlying concepts are universal. Once you understand the workflow structure, you can apply it to any CI system.

Seeing It In Action

Let’s walk through a real scenario. Santa’s elves need to add an emergency gift bag for a last-minute delivery route. We make the change in SysML, commit our changes to the repository, and voilà – the report gets generated automatically: new bag and its contents added to the report, all weight calculations updated, and safety margins recalculated.

All without manual intervention. The model changed, the pipeline ran, and the documentation was updated.

You can explore the automation and its artifacts at our GitHub Actions page (as well as check out the updated Santa’s Sleigh 2025 BOM report).

What Makes This Powerful

CI/CD addresses fundamental challenges in model-based systems engineering:

• Immediate validation: Every change is validated automatically. Errors in calculations, constraint violations, and syntax issues are caught at commit time, not discovered weeks later during integration or review. The pipeline fails immediately with specific error messages.
• Synchronized deliverables: Stakeholders have access to the latest documentation because reports regenerate automatically on every model change. The model is the single source of truth, and all deliverables stay synchronized without manual coordination.
• Enforced quality standards: Define quality checks once, enforce them consistently. Require documentation on every component, verify margins stay within thresholds, and ensure interface compatibility. Standards become automated gates rather than manual review checklist items.
• Complete traceability: Every change triggers validation and regeneration, creating a complete audit trail. The Git history shows what changed, when it changed, what validation it passed, and what deliverables were updated. Perfect for compliance and design reviews.
• Confident collaboration: Multiple engineers working on different subsystems can integrate changes confidently. The pipeline catches integration issues automatically when changes are merged, preventing subtle errors from propagating through the system undetected.

The workflow you built today (automated validation, report generation, and publishing) is foundational. CI/CD for models can do a lot more: verify that all connections between components have compatible types and units, generate traceability matrices showing which requirements are satisfied by which design elements, automatically flag any parameters exceeding allocations, verify interfaces, create different views and diagrams, and so on.

Each of these capabilities follows the same pattern: define the logic once, integrate it into your pipeline, and it runs automatically. The infrastructure is in place. Now you can extend it to enforce the quality standards and generate the deliverables your project needs.

Challenge for Today

For today’s challenge, we encourage you to think about the automation possibilities for your own projects:

1. What quality checks would you want to automate? Think about validation rules that should run on every change – constraint verification, documentation completeness, interface compatibility checks.
2. What reports would you want to generate automatically? Consider the deliverables your stakeholders need – BOMs, traceability matrices, interface specifications, mass budgets.
3. What would a “fail fast” policy look like for your models? What errors should immediately stop the pipeline and notify the team?

The infrastructure patterns you learned today (validate, generate, publish) apply to any automation you want to build. The key is identifying which manual tasks in your current workflow could benefit from consistent, automatic execution.

Share your ideas and questions in our community forum – we’d love to hear what automation opportunities you see in your projects!

Summary

In this lesson, you learned how CI/CD practices from software development can transform your systems engineering workflow. You saw how automated pipelines validate models, generate reports, and publish deliverables on every commit – eliminating manual synchronization and catching errors immediately.

This automation is possible because SysML v2 is textual (enabling version control and processing) and executable (enabling programmatic analysis with Syside Automator). Combined with Git for version control and Sysand for package management, CI/CD completes your systems-as-code infrastructure.

You explored a complete pipeline that validates the sleigh model, generates a comprehensive BOM with executive summaries, reindeer rosters, and cargo manifests, and then publishes everything to GitHub Pages. The model changed, the pipeline ran, and stakeholders got updated documentation – all without manual intervention.

Tomorrow, we continue building your SysML v2 capabilities. Until then, head to Syside Cloud to reflect on today’s lesson. Happy automating!