Source Control, Builds & CI/CD
Manage code with Azure DevOps version control, implement branching strategies, resolve conflicts, and set up CI/CD pipelines for F&O deployments.
Source Control, Builds & CI/CD
Your code is too valuable to lose and too complex to merge manually. This module covers version control with Azure DevOps, branching strategies for F&O teams, and automating builds and deployments with CI/CD pipelines.
Think of source control as a time machine for your code.
Source control saves every version of your code, so you can always go back in time. Two developers can work on different parts of the same project without overwriting each other. Branching creates a parallel copy — you work on a feature without disturbing the main code, then merge when ready. CI/CD automates the tedious parts: every time you check in code, a robot builds it, runs tests, and packages it for deployment.
TFVC vs Git
| Aspect | TFVC (Centralised) | Git (Distributed) |
|---|---|---|
| Model | Centralised — server is the single source of truth | Distributed — every developer has a full copy |
| Check-in/out | Explicit check-out locks files | No locks — merge on push |
| Branching | Heavy — branches are server-side copies | Lightweight — branches are pointers |
| Offline work | Limited — need server connection to check out | Full — commit locally, push when connected |
| F&O history | Traditional choice, deeply integrated | Growing adoption with UDE |
| Merge experience | Visual Studio merge tool | Git merge/rebase tools |
| Best for | Teams familiar with centralised workflows | Modern teams, multiple parallel features |
🏗️ Vik’s preference: “At Axion we use TFVC for most F&O projects because the check-out model prevents merge conflicts on complex AOT elements. But for new UDE projects, we are starting to use Git. The exam expects you to know both.”
Daily Version Control Workflow
With TFVC
- Get latest — pull the newest code from the server
- Check out — lock the file you want to edit
- Edit — make your changes in Visual Studio
- Build — compile and verify no errors
- Check in — upload your changes with a descriptive comment
- Resolve conflicts — if someone changed the same file, merge
With Git
- Pull — get latest from the remote repository
- Create a branch — work in isolation (e.g.,
feature/add-credit-hold) - Commit — save changes locally with a message
- Push — upload your branch to Azure DevOps
- Pull request — request review and merge into main
- Resolve conflicts — merge or rebase if branches diverged
Exam tip: Check-in policies
Azure DevOps supports governance rules: for TFVC, these are check-in policies (work item association, code review required, build verification, comment required). For Git, the equivalent is branch policies on pull requests (required reviewers, build validation, linked work items). The exam may ask what prevents a developer from checking in unvalidated code — policies are the answer.
Branching Strategies
Recommended F&O branching model
| Branch | Purpose | Who Uses It |
|---|---|---|
| Main (or trunk) | Stable, tested code | Release baseline |
| Dev | Active development | All developers |
| Feature branches | Isolated feature work | Individual developers |
| Release | Release candidate stabilisation | Release managers |
| Hotfix | Emergency production fixes | On-call developers |
Workflow: Feature branch → merge to Dev → test in sandbox → merge to Main → deploy to production
Resolving Conflicts
When two developers change the same file:
- Visual Studio detects the conflict during check-in or merge
- The merge tool shows three panes: your version, their version, and the result
- Choose which changes to keep, or manually combine both
- Build and test the merged code before completing the check-in
Build Automation & CI/CD
Build pipeline
A build pipeline in Azure DevOps compiles your F&O code and produces a deployable package automatically.
| Step | What Happens |
|---|---|
| Trigger | A check-in or scheduled trigger starts the build |
| Get sources | Pipeline pulls latest code from version control |
| Build | Compiles X++ code using the F&O build tools |
| Run tests | Executes SysTest unit tests |
| Package | Creates a deployable package (.zip) |
| Publish | Uploads the package to Azure DevOps artifacts or LCS |
Continuous deployment
After the build produces a package, a release pipeline can:
- Upload the package to the LCS Asset Library (via LCS API)
- Trigger deployment to a sandbox environment
- Run automated smoke tests
- Notify the team of success or failure
👨💻 Elena’s CI/CD setup at PacificForge: “Every check-in triggers a build. If the build or tests fail, the developer gets an email within 15 minutes. Packages that pass are automatically uploaded to LCS. Our release manager just clicks ‘deploy to sandbox’ — the package is already waiting.”
| Aspect | Manual (Visual Studio) | Automated (Azure DevOps Pipeline) |
|---|---|---|
| Triggered by | Developer clicks Build | Automatic on check-in or schedule |
| Consistency | Depends on developer's environment | Clean, reproducible build agent |
| Tests | Developer must remember to run them | Automatically runs full test suite |
| Package output | Local deployable package | Published to artifacts/LCS |
| Notification | Developer sees the result | Team notified via email or Teams |
Sophie and Nikhil are both working on the same X++ class. Sophie checks in first. When Nikhil tries to check in, he gets a conflict. What should he do?
Elena wants every code check-in to automatically compile the code, run tests, and produce a deployable package. What should she configure?
Vik needs to choose between TFVC and Git for a new F&O project. The team has 8 developers, all working on-site, and they want to prevent two people from editing the same file simultaneously. Which system is better suited?
Next up: Domain 3 begins — Tables: Fields, Relations & Indexes — start building the data model that powers every F&O application.