[Paper] PPTAM$η$: Energy Aware CI/CD Pipeline for Container Based Applications

Source: arXiv - 2602.12081v1

Overview

The paper introduces PPTAM η, an automated CI/CD extension that injects power‑and‑energy measurement into the standard GitLab pipeline for container‑based micro‑services. By making energy consumption visible at every commit, the authors show how developers can start treating energy as a first‑class quality metric alongside latency and throughput.

Key Contributions

• Energy‑aware CI/CD pipeline – a plug‑in for GitLab CI that automatically triggers load generation, container monitoring, and hardware power‑probe reads for each build.
• End‑to‑end measurement framework – combines software metrics (CPU, memory, network) with hardware‑level power data from a plug‑in power meter, ensuring comparable numbers across commits.
• Version‑level comparison – stores per‑commit energy and performance results in a searchable artifact repository, enabling test engineers to spot regressions instantly.
• Trend analysis tooling – visual dashboards that plot energy vs. time, helping researchers study the impact of code smells, refactorings, or design patterns on power usage.
• Empirical validation – a case study on a JWT‑protected API across four successive commits, demonstrating that even small code changes can shift energy consumption by measurable percentages.

Methodology

1. Pipeline Integration – The authors extended a GitLab CI YAML file with three new stages:

   • Load Generation – a lightweight traffic generator (e.g., hey or wrk) issues a fixed request pattern against the API.
   • Container Monitoring – Docker stats and Prometheus scrape CPU, memory, and network counters from each container.
   • Power Measurement – a USB‑C power probe (e.g., WattsUp? or a similar device) records real‑time wattage from the host machine.

2. Synchronization – All three data streams are timestamped and stored in a SQLite/InfluxDB time‑series DB, guaranteeing that energy numbers line up with the exact load phase.

3. Automation & Reporting – After each pipeline run, a Python post‑processor aggregates the raw data into per‑commit summaries (average power, total energy (Joules), latency percentiles, etc.) and pushes a JSON artifact to GitLab’s package registry.

4. Validation – The authors ran the pipeline on a simple Flask‑based API protected by JWT tokens, committing four incremental changes (e.g., adding a logging statement, refactoring a request handler). They compared the resulting energy and performance numbers to verify repeatability.

Results & Findings

• Energy sensitivity – A single extra print statement (v1.2) increased average power by ~7 % and total energy by ~6 %, while latency grew modestly.
• Correlation with performance – Most energy changes mirrored latency shifts, but some optimizations (e.g., caching) cut energy without a noticeable latency impact, highlighting hidden savings.
• Repeatability – Running the same commit three times produced <2 % variance, confirming that the measurement setup is stable enough for CI use.

Practical Implications

• Developer feedback loop – Teams can now see a “energy badge” on merge requests, preventing accidental regressions before they hit production.
• Cost‑aware scaling – Ops teams can use per‑commit energy data to predict power budgets for Kubernetes clusters, potentially reducing cloud‑provider electricity charges.
• Green‑by‑design tooling – The pipeline can be combined with static analysis tools that flag known energy‑hungry patterns, guiding refactoring decisions.
• Benchmarking SaaS APIs – Companies offering public APIs can publish energy footprints per endpoint, differentiating themselves in an increasingly sustainability‑focused market.

Limitations & Future Work

• Hardware dependency – Accurate wattage readings require a dedicated power probe on the host; the approach is less portable to fully virtualized CI runners or serverless environments.
• Scope limited to single‑host containers – Multi‑node Kubernetes clusters introduce network‑level power consumption that the current setup does not capture.
• Workload realism – The case study uses synthetic HTTP traffic; future work should evaluate real‑world production traces and diverse micro‑service topologies.
• Automation of baseline selection – The authors plan to add statistical change‑detection algorithms to automatically flag significant energy regressions without manual threshold tuning.

By embedding energy awareness directly into the CI/CD workflow, PPTAM η opens the door for developers to treat sustainability as a measurable, actionable quality attribute—turning “green coding” from a buzzword into a concrete engineering practice.

Authors

• Alessandro Aneggi
• Xiaozhou Li
• Andrea Janes

Paper Information

• arXiv ID: 2602.12081v1
• Categories: cs.SE
• Published: February 12, 2026
• PDF: Download PDF