This is where Gatling truly shines compared to JMeter. Because Gatling tests are code in a Maven project, integrating them into CI/CD is natural. No special plugins to install on your CI server. No binary .jmx files to manage. Just "mvn gatling:test" in your pipeline. If assertions fail, the command returns a non-zero exit code, and your build fails. That is it.
pipeline {
agent any
stages {
stage('Build Application') {
steps {
sh 'mvn clean package -DskipTests'
}
}
stage('Deploy to Staging') {
steps {
sh './deploy-staging.sh'
// Wait for deployment to be healthy
sh 'curl --retry 10 --retry-delay 5 http://staging:8080/health'
}
}
stage('Performance Test') {
steps {
dir('perf-tests') {
sh 'mvn gatling:test -Dgatling.simulationClass=com.example.LoadTest'
}
}
post {
always {
// Archive the HTML report as a build artifact
archiveArtifacts artifacts: 'perf-tests/target/gatling/**/index.html',
fingerprint: true
// Publish Gatling report (requires Gatling Jenkins plugin)
gatlingArchive()
}
}
}
}
post {
failure {
slackSend(channel: '#perf-alerts',
message: "Performance test FAILED on build ${env.BUILD_NUMBER}")
}
}
}name: Performance Test
on:
push:
branches: [main]
schedule:
- cron: '0 6 * * 1-5' # Weekdays at 6 AM
jobs:
performance-test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Set up Java 17
uses: actions/setup-java@v4
with:
distribution: temurin
java-version: 17
cache: maven
- name: Run Gatling Tests
working-directory: perf-tests
run: mvn gatling:test -Dgatling.simulationClass=com.example.LoadTest
- name: Upload Gatling Report
if: always() # Upload even if test fails
uses: actions/upload-artifact@v4
with:
name: gatling-report-${{ github.sha }}
path: perf-tests/target/gatling/**/index.html
retention-days: 30In CI/CD, you need to point tests at different environments (staging, pre-prod) and adjust load levels. Use system properties to make simulations configurable without code changes.
public class ConfigurableSimulation extends Simulation {
// Read from system properties with defaults
String baseUrl = System.getProperty("baseUrl", "https://www.testerrank.com");
int targetUsers = Integer.parseInt(
System.getProperty("targetUsers", "100")
);
int rampDuration = Integer.parseInt(
System.getProperty("rampDuration", "60")
);
int steadyDuration = Integer.parseInt(
System.getProperty("steadyDuration", "300")
);
HttpProtocolBuilder httpProtocol = http
.baseUrl(baseUrl)
.acceptHeader("application/json");
ScenarioBuilder loadTest = scenario("Configurable Load")
.exec(
http("Health Check").get("/health")
.check(status().is(200))
)
.pause(Duration.ofSeconds(1), Duration.ofSeconds(3))
.exec(
http("Home Page").get("/")
.check(status().is(200))
);
{
setUp(
loadTest.injectOpen(
rampUsers(targetUsers).during(Duration.ofSeconds(rampDuration)),
constantUsersPerSec(targetUsers / 10.0)
.during(Duration.ofSeconds(steadyDuration))
)
).protocols(httpProtocol)
.assertions(
global().responseTime().percentile(95.0).lt(2000),
global().successfulRequests().percent().gt(99.0)
);
}
}# Local development - light load
mvn gatling:test \
-DbaseUrl=https://www.testerrank.com \
-DtargetUsers=10 \
-DrampDuration=10 \
-DsteadyDuration=30
# Staging - moderate load
mvn gatling:test \
-DbaseUrl=https://staging.example.com \
-DtargetUsers=200 \
-DrampDuration=60 \
-DsteadyDuration=300
# Pre-production - full load
mvn gatling:test \
-DbaseUrl=https://preprod.example.com \
-DtargetUsers=1000 \
-DrampDuration=120 \
-DsteadyDuration=600Q: How do you integrate Gatling performance tests into a CI/CD pipeline?
A: Gatling integrates naturally with CI/CD because tests are Maven or Gradle projects. In the pipeline, I run "mvn gatling:test" after deploying to a staging environment. If any assertion fails -- like p95 exceeding 2 seconds or success rate dropping below 99% -- the Maven command returns a non-zero exit code, which fails the build automatically. I configure simulations with system properties so the same test runs with light load on every deploy (50 users, quick feedback) and heavy load on nightly runs (500+ users, thorough testing). I always archive the Gatling HTML reports as build artifacts for historical comparison. In Jenkins, the Gatling plugin renders trend charts across builds. In GitHub Actions, I upload reports as artifacts. The key insight is that performance regression detection in CI should be fast -- a 2-minute test with 50 users catches 80% of issues.
Do not run heavy load tests as part of your PR checks -- they take too long and block the merge queue. Run a quick smoke test (10-20 users, 30 seconds) in PRs, and full load tests on the main branch after merge or on a nightly schedule.
Key Point: Gatling + Maven + CI/CD = automated performance regression detection. Use system properties for environment config. Light tests on every deploy, full tests on schedule.
Key Point: Gatling integrates natively with CI/CD via Maven -- light tests per deploy, full tests on schedule, reports as artifacts