03. DevOps about Deploy
DevOps about Deploy
Prerequisites
1
2
- Docker
- C++
1. What is Deploy in DevOps?
The Deploy phase is where the built artifact is delivered into a target environment so it can actually run.
For a C++ system, deployment is not just “copy the executable somewhere.” It also includes:
- packaging the application
- preparing runtime dependencies
- defining the target environment
- releasing the artifact safely
Deploy is the phase where a tested build artifact is released into a target environment so it can run reliably in production.
2. Why Deployment Matters
A program can build successfully and still fail after deployment.
Typical reasons:
- missing shared libraries
- different OS or compiler environments
- incorrect runtime configuration
- wrong file paths or permissions
- inconsistent deployment steps
❌ Without a proper deployment process
- “works on my machine” problems
- broken production releases
- hard-to-reproduce environment issues
- manual mistakes during release
✔ With a proper deployment process
- repeatable releases
- consistent runtime environment
- safer rollouts
- easier rollback when needed
3. Deploying a Real-Time Image Preprocessing System
Assume we built:
A C++ real-time image preprocessing service for industrial inspection
The system may:
- receive live image frames
- preprocess them in real time
- provide output to downstream modules
- run continuously in production
For this kind of system, deployment must ensure:
- correct runtime environment
- stable performance
- minimal interruption
- predictable behavior after release
4. Goals of the Deploy Phase
The Deploy phase should guarantee:
- the correct artifact is released
- the target environment is consistent
- runtime dependencies are available
- the system starts successfully
- the release can be validated and rolled back if needed
5. What Gets Deployed?
In C++, deployment usually includes more than just the executable.
Possible artifacts:
- executable binary
- shared libraries
- configuration files
- model/data files
- startup scripts
- container image
Example
1
2
3
4
5
deploy/
├── app
├── config.yaml
├── libopencv_core.so
└── start.sh
Or as a container:
1
2
docker image
└── app + dependencies + runtime environment
6. Why Containers Are Common for Deployment
A modern deployment approach is to package the application in a container.
This is useful because C++ applications often depend on:
- shared libraries
- compiler/runtime compatibility
- specific OS packages
Using Docker helps make the runtime environment reproducible.
Example Dockerfile
```dockerfile id=”q8h5tr” FROM ubuntu:22.04
RUN apt-get update && apt-get install -y
libstdc++6
WORKDIR /app
COPY build/app ./app COPY config.yaml ./config.yaml
CMD [”./app”]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
##### Benefits
* same runtime environment everywhere
* easy CI/CD integration
* easier rollback and versioning
* fewer environment mismatch issues
## <b>7. Deployment Flow in DevOps</b>
A typical flow looks like this:
```text
Code
↓
Build
↓
Test
↓
Package artifact
↓
Deploy to target environment
↓
Validate release
In many teams:
1
2
3
4
5
6
7
8
9
GitHub Actions
↓
Build binary
↓
Build Docker image
↓
Push image to registry
↓
Deploy to server / cloud
8. Deployment Targets
Deployment depends on where the application runs.
8-1. Bare-metal or local server
Used for industrial systems or on-premise environments
8-2. VM / cloud instance
AWS EC2
8-3. Container platform
Docker-based deployment, Kubernetes
8-4. Edge device / embedded Linux
Often used when the system must run near hardware
For a real-time image preprocessing system, deployment often happens on:
- factory servers
- edge devices
- dedicated processing machines
- cloud-connected operational nodes
9. What Must Be Checked During Deployment
Deployment is not finished when the file is copied.
You must verify:
- does the process start correctly?
- are required libraries available?
- is configuration loaded correctly?
- are permissions correct?
- are input/output paths valid?
- is runtime performance still acceptable?
Example Post-Deployment Validation
After deployment:
1
2
3
4
5
- Service starts successfully
- Frame input is received
- Output is generated correctly
- CPU / memory usage is normal
- Latency remains within target
10. Common Deployment Risks
❌ Missing runtime libraries
The binary runs locally but fails in production
❌ Wrong build artifact
Debug build accidentally deployed instead of Release
❌ Config mismatch
Wrong file paths, ports, or device settings
❌ Environment mismatch
Different OS packages or library versions
❌ Manual deployment mistakes
Copying wrong files or missing steps
11. Deployment Strategies
Not all deployments should replace production immediately.
Common strategies:
11-1. Full replacement
Old version is stopped, new version starts
Simple, but may cause downtime
11-2. Rolling deployment
Gradually replace running instances
Better for availability
11-3. Blue-green deployment
Keep two environments:
- Blue = current production
- Green = new version
Switch traffic only after validation
11-4. Canary deployment
Release to a small subset first. Useful for reducing production risk
For industrial or real-time environments, the strategy depends on:
- downtime tolerance
- hardware constraints
- operational risk
12. Rollback Matters
A good deployment process always considers failure.
If the new version causes issues, rollback should be possible.
Rollback may mean:
- redeploy previous binary
- restart previous container image
- switch back to old environment
Deployment is not complete unless recovery is possible.
13. Deployment Automation
In DevOps, deployment should be automated whenever possible. Manual deployment creates risk. A simple automated flow might look like this:
1
2
3
4
5
6
7
8
9
10
11
12
13
git push
↓
CI builds project
↓
tests pass
↓
Docker image created
↓
image pushed to registry
↓
server pulls new image
↓
service restarts
- fewer human errors
- faster release cycle
- repeatable process
- easier auditing
14. Common Mistakes in the Deploy Phase
❌ Treating deployment as simple file copying
There are runtime dependencies and environment assumptions
❌ Deploying without validation
Application may start but behave incorrectly
❌ No rollback plan
One bad release can break production
❌ Manually changing production machines
Creates drift and inconsistency
❌ Ignoring performance after deployment
A system may function correctly but still fail latency targets