Workflow Source Control and Deployment
This section explains how to use Integration Soup workflow files with source control and deployment automation.
Integration Soup treats the workflow directory as a local folder of current workflow files. Source control, CI/CD, and deployment tooling sit around that folder.
Start here
- Read Workflow Directory and Source Control first.
- If you use GitHub, continue to GitHub Integration.
- If you use another git-based platform, continue to Generic Git Patterns.
- For Docker, multiple servers, or load-balanced deployments, read Deployment Patterns.
Decision guide
| If you need to... | Start with... |
|---|---|
| Understand how Integration Soup loads, saves, deletes, and imports workflow files | Workflow Directory and Source Control |
| Use GitHub as the main repository and deployment control plane | GitHub Integration |
| Apply the same ideas to GitLab, Azure DevOps, Bitbucket, or self-hosted git | Generic Git Patterns |
| Roll out the same workflow set to Docker containers or multiple hosts | Deployment Patterns |
Product boundary
Integration Soup:
- reads and writes local workflow files
- imports workflows from the local workflow directory
- can detect newly dropped workflow files automatically or on restart
External tooling typically provides:
- run
git pull,git push, orgit commit - choose a branch strategy for you
- deploy workflow files to remote machines
- orchestrate container rollout or load-balancer changes
Those parts are handled by external tooling such as git clients, deployment scripts, GitHub Actions, GitLab CI, Azure DevOps pipelines, container orchestration, or configuration management tools.