Development Environment and Repository Standards

Before releasing a service, the repository must follow the technical standards adopted by the RPA team.

A typical repository should contain the application code, Docker configuration, environment examples, and documentation.

Expected repository structure

repository/
├── src/
│   └── ...
├── docker
│    ├── Dockerfile
|    ├── compose.local.yaml
|    ├── compose.dev.yaml
|    ├── compose.test.yaml
|    └── compose.yaml
├── .env.example
├── pyproject.toml
└── README.md

Application code

Application code should be contained in:

src/

Docker Compose files

The repository should contain the Compose configurations required by the project.

For a service supporting all standard environments, this may include:

compose.local.yaml
compose.dev.yaml
compose.test.yaml
compose.yaml

The exact naming convention must remain consistent with the standards adopted by the project or team.

Environment example

The repository should contain an example environment file:

.env.example

This file must contain the variables required by the application without containing real secrets.

Example:

APP_ENV=local
LOG_LEVEL=INFO
DB_HOST=
DB_PORT=
DB_NAME=
DB_USER=
DB_PASSWORD=
SECRET_KEY=

Real .env files must not be committed to GitLab.

Docker volume mounts

Docker Compose volume mounts must be portable between machines.

Use relative paths:

volumes:
  - ./data:/app/data
  - ./logs:/app/logs

Avoid developer-specific absolute paths:

volumes:
  - /home/user/project/data:/app/data

Absolute local paths are not portable and may not exist on the target Release VM.

Remote images

Remote environments should run using Docker images already published to the internal GitLab Container Registry.

The remote environment should not depend on having the complete source repository available on the VM.

The deployment should be based on:

Docker image.
Docker Compose.
Environment configuration.
External files, if required.