> For the complete documentation index, see [llms.txt](https://docs.poja.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.poja.io/getting-started/ci-cd.md).

# CI/CD

Poja automates the full delivery pipeline for your Spring Boot application. Every push to a tracked branch triggers a sequence of checks, a build, and a deployment — with no pipeline configuration required on your part.

### How branches map to environments <a href="#how-branches-map-to-environments" id="how-branches-map-to-environments"></a>

Poja uses your Git branches directly as deployment targets:

| <p>Branch</p><p><i class="fa-solid">:solid:</i></p> | <p>Environment</p><p><i class="fa-solid">:solid:</i></p> |
| --------------------------------------------------- | -------------------------------------------------------- |
| `preprod`                                           | Preprod (staging)                                        |
| `prod`                                              | Prod (live)                                              |

Pushing a commit to either branch is the only action needed to trigger a deployment. No manual triggers, no deployment scripts.

Any other branch (feature branches, hotfixes) runs CI only — tests and format checks — but does not deploy.

### The two workflows <a href="#the-two-workflows" id="the-two-workflows"></a>

Poja generates two GitHub Actions workflows in `.github/workflows/` when it creates your repository. You do not need to edit them.

#### `ci.yml` — triggered on every push, every branch <a href="#ciyml-triggered-on-every-push-every-branch" id="ciyml-triggered-on-every-push-every-branch"></a>

Runs in parallel:

**Format job**\
Runs `./format.sh` and checks that no files were modified. If your code is not correctly formatted, this job fails.

**Test job**\
Runs `./gradlew test`. This includes:

* Unit tests
* Integration tests (Testcontainers spins up a real PostgreSQL instance)
* JaCoCo coverage verification

{% hint style="info" %}
JaCoCo min coverage

Minimum code coverage can be configured via the Jacoco Min Coverage field on your environment’s configuration, if your code coverage drops below the specified value, the job will fail
{% endhint %}

<figure><img src="https://cdn.document360.io/0fb568fc-53e8-425d-a7e7-77f693fe95a4/Images/Documentation/image(26).png" alt=""><figcaption></figcaption></figure>

#### `cd-compute.yml` — triggered on push to `preprod` or `prod` <a href="#cdcomputeyml-triggered-on-push-to-preprod-or-prod" id="cdcomputeyml-triggered-on-push-to-preprod-or-prod"></a>

| Step                   | Description                                                                 |
| ---------------------- | --------------------------------------------------------------------------- |
| Build your application | Runs `sam build` to compile your app into an AWS Lambda-compatible artifact |
| Upload artifact        | Zips the artifact and uploads it to a Poja-managed S3 bucket                |
| Trigger deployment     | Calls Poja's API to deploy the uploaded artifact to your environment        |

The full CD pipeline completes in under 10 minutes.

### Code formatting <a href="#code-formatting" id="code-formatting"></a>

Poja ships a formatter based on [Google Java Format](https://github.com/google/google-java-format).\
Run it locally before pushing to avoid a CI failure:

{% code title="Bash" %}

```bash
# macOS / Linux
./format.sh

# Windows
.\format.bat
```

{% endcode %}

The `format` CI job runs `./format.sh` and then checks `git diff --exit-code`. If any file differs from the formatted version, the job fails.<i class="fa-regular">:regular:</i>