Introduction
When building the AdventureTube CI/CD pipeline, I need to address three key questions to ensure an efficient and scalable build process: managing multiple build environments, establishing an ideal build process, and automating testing.
How Multiple Build Environments are Managed
This system is built on two core concepts: centralized configuration and externalization.
Centralized configuration consolidates all configurations into a single location using Spring Cloud Config, storing and managing configurations for all sub-modules in one central repository.
Externalization uses Java ENV dependencies to manage environment-specific variables. Instead of hardcoding configurations, I use environment variable files at the Docker Compose level.
Currently four environment files:
env.mac— local development on macOSenv.pi— testing on Raspberry Pienv.pi2— secondary Pi testing environmentenv.prod— production deployment
The key variable SPRING_PROFILES_ACTIVE determines which environment profile Spring will load. A custom EnvironmentPostProcessor reads the active profile from Docker Compose and loads the corresponding environment file before Spring initializes.
The Ideal Build Process
The build process consists of three components:
1. Development Environment (Local)
Work on Mac without containerizing microservices. This simplifies development and debugging while preserving computing power.
2. QA Server Deployment
Push changes to GitHub → triggers Jenkins webhook → Jenkins master instructs slave to pull code, build image, run updated container, and clean up old container.
3. Production Deployment
After code is committed and pushed, QA and local containers should have identical source code. This allows remote debugging using specific ports assigned to different modules.