Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/infra-neo/CICD/llms.txt

Use this file to discover all available pages before exploring further.

The CI/CD stack supports four deployment workflows suited to different team setups and project requirements. Choose Git-based for standard CI/CD automation, ZIP-based for applications without direct Git access, manual for rapid local testing, or parameterized for environment-specific deployments that give you full control over where and how your application is deployed.

​
Workflow 1: Standard Git-Based Deployment

The standard Git-based workflow is the recommended path for teams with a shared repository. Jenkins detects commits automatically and runs the full pipeline — from security scanning through to application server deployment — without any manual intervention.
1

Push code to Git

Commit and push your changes to the repository:
git add .
git commit -m "My changes"
git push origin main
2

Jenkins detects the change

Jenkins picks up the commit via a webhook trigger or SCM polling, and starts a new pipeline build automatically.
Set up a Git webhook pointing to http://localhost:8080/github-webhook/ (or your Jenkins URL) for near-instant triggering on every push. Polling introduces a delay of up to the configured interval, which is typically one minute.
3

Pipeline executes all stages

The pipeline runs the following stages in order:
  1. Read build-config.yml — loads Java version, Maven version, build tool, and appserver target
  2. Checkout — clones the latest source from SCM
  3. Security scan — scans src/ for hardcoded passwords, API keys, and tokens; fails the build if any are found
  4. Build — runs mvn clean install with the environment flag and the generated APP_VERSION
  5. Test — runs mvn test and publishes JUnit results
  6. SonarQube analysis — uploads code quality metrics with sonar:sonar
  7. Quality Gate — waits up to 5 minutes for SonarQube to pass the gate; aborts the pipeline if it fails
  8. Deploy to Nexus — uploads the WAR artifact to maven-snapshots repository
  9. Deploy to WildFly/JBoss — copies the WAR to the target application server’s deployments directory

​
Workflow 2: ZIP-Based Deployment

Use the ZIP-based workflow for applications that live outside of Git — legacy codebases, third-party deliverables, or air-gapped environments. The upload-source.sh script handles everything from extraction to deployment.
1

Create a ZIP of your source code

Package the source directory and Maven POM together:
zip -r myapp-source.zip src/ pom.xml
2

Upload and build with the script

Run upload-source.sh with the ZIP file, target environment, and application server:
./upload-source.sh myapp-source.zip dev wildfly
Full usage:
./upload-source.sh <path-to-zip> [environment] [target-server]
ArgumentRequiredDescription
path-to-zipYesPath to the ZIP file containing source code
environmentNoTarget environment: dev, staging, or prod (default: dev)
target-serverNoApplication server: wildfly or jboss (default: wildfly)
3

What the script does internally

Once invoked, upload-source.sh performs the following steps in order:
  1. Validates arguments — checks that the ZIP file exists and that the environment and target server values are valid
  2. Extracts the ZIP — creates a temp directory via mktemp -d and unpacks the archive into it via unzip
  3. Locates pom.xml — searches for the project root using find
  4. Loads environment properties — reads config/environments/<env>/application.properties and exports values as environment variables
  5. Creates a local Maven repository — creates .m2/repository-<env> inside the project directory for environment-isolated dependency caching
  6. Scans for hardcoded passwords — greps src/ for literal password assignments; exits with an error if any are found
  7. Builds with Maven — runs mvn clean install with the environment flag and a generated build version
  8. Runs tests — executes mvn test; stops if tests fail
  9. Deploys the WAR — copies the built WAR file to the running container via docker cp
  10. Cleans up — removes the temp directory created in step 2

​
Workflow 3: Manual Maven Build

For local testing or one-off deployments, you can build and deploy without Jenkins. This is the fastest way to verify a change on a running application server.
1

Build the project locally

cd examples/webapp-sample && mvn clean package
2

Deploy to WildFly

Copy the generated WAR directly into WildFly’s hot-deploy directory:
docker cp target/*.war wildfly:/opt/jboss/wildfly/standalone/deployments/
3

Deploy to JBoss (alternative)

Use the same docker cp pattern against the JBoss container:
docker cp target/*.war jboss:/opt/jboss/wildfly/standalone/deployments/
4

Access the deployed application

WildFly monitors the deployments directory and hot-deploys the WAR automatically. Access it at:
http://localhost:8090/webapp-sample-1.0.0-SNAPSHOT/
For JBoss, substitute port 8070.

​
Workflow 4: Jenkins Pipeline with Parameters

The parameterized pipeline gives you full control at build time — choose the environment, target server, and whether to skip tests or SonarQube analysis. This is the standard workflow for deployment to staging and production.
1

Create a parameterized pipeline job

In Jenkins, create a new Pipeline job. Under General, check This project is parameterized.
2

Configure pipeline parameters

Add the following parameters to match what Jenkinsfile.enhanced declares:
ParameterTypeOptions / DefaultDescription
ENVIRONMENTChoicedev, staging, prodTarget deployment environment
TARGET_SERVERChoicewildfly, jbossTarget application server
SKIP_TESTSBooleanfalseSkip running Maven tests
SKIP_SONARBooleanfalseSkip SonarQube analysis and Quality Gate
FROM_ZIPBooleanfalseBuild from an uploaded ZIP file instead of SCM
3

Point the job to Jenkinsfile.enhanced

Under Pipeline → Definition, select Pipeline script from SCM. Set the Script Path to Jenkinsfile.enhanced (or copy it to Jenkinsfile at the repository root).
4

Run with Build with Parameters

Click Build with Parameters in the Jenkins job. Select the desired environment and server, adjust test/scan toggles as needed, then click Build. The pipeline will run only the stages that apply to your selections.

​
Environment-Specific Properties

The enhanced pipeline automatically loads configuration from the config/environments/ directory based on the ENVIRONMENT parameter. This lets each environment carry its own database URLs, API endpoints, log levels, and other settings without changing any source code. At the Load Environment Properties stage, the pipeline reads: 
config/environments/${ENVIRONMENT}/application.properties
The full directory layout supports per-application overrides within each environment: 
config/environments/
├── dev/
│   ├── application.properties
│   ├── database.properties
│   └── settings.xml
├── staging/
│   ├── application.properties
│   ├── database.properties
│   └── settings.xml
└── prod/
    ├── application.properties
    ├── database.properties
    └── settings.xml
A sample dev/application.properties looks like: 
app.name=myapp
app.version=${APP_VERSION}
app.environment=development

# Database
db.url=jdbc:postgresql://postgres:5432/devdb
db.username=devuser
db.password=${DB_PASSWORD_DEV}

# External Services
api.url=http://dev-api.example.com
api.key=${API_KEY_DEV}
Secrets are never stored in these files — they are referenced as environment variables and injected at runtime via Jenkins credentials or Docker environment configuration.
For the full enhanced pipeline configuration, including all stage definitions and post-build steps, see Jenkinsfile Enhanced.

Build docs developers (and LLMs) love

Get started for freeTalk to us