How to - ENG

#

How to

RPA Service Deployment Guide

1. Purpose of this guide

This guide describes the standard process for preparing, deploying, and updating RPA services developed by Automators within the working group.

#The Guidaaim alis rilascioto deiensure servizithat RPA

each

##service 1.is Obiettivo della guida

Questa guida descrive il processo standard per preparare, rilasciare e aggiornare i servizi RPA sviluppati dagli Automator all’interno del gruppo di lavoro.

L’obiettivo è garantire che ogni servizio venga rilasciatodeployed in modoan ordinato,organized, tracciabile,traceable, ripetibileand erepeatable conway, ilwith minoras numerofew possibileunexpected diissues imprevisti,as rispettandopossible, lefollowing best practicethe Python, Docker, GitLabGitLab, eand DevOps adottatebest dalpractices gruppoadopted RPA.by the RPA group.

Per“Service “rilasciodeployment” dimeans uninstalling servizio”and sirunning intendea l’installazioneservice eon l’esecuzionea delremote serviziomachine su una macchina remota, utilizzandousing Docker Compose, immaginiimages pubblicatepublished sulto registrythe repository’s GitLab delregistry, repositoryand eenvironment-specific fileconfiguration difiles.

configurazione

---

specifici

2. perRoles ambiente.involved

2.1 RPA Developer / Team Lead

Responsible for developing the service and preparing the technical aspects of deployment.

---Responsibilities include:

#

2.developing Attorithe coinvolticode;

##

following 2.1 Sviluppatore / TLthe RPA

Ègroup’s ilPython responsabileand dello sviluppo del servizio e della preparazione tecnica del rilascio.

Si occupa di:

- sviluppare il codice;
- rispettare leDocker best practicepractices;

Python e Docker del gruppo RPA;
- predisporre i filepreparing Docker Compose perfiles ifor varithe ambienti;
-various testareenvironments; iltesting serviziothe localmente;
-service buildarelocally; ebuilding pubblicareand lepublishing immaginiDocker Docker,images, tramitethrough CI oor manualmente;
-manually; prepararepreparing ilthe .env file `.env`for perthe l’ambientetarget target;
-environment; salvarestoring lesensitive configurazioniconfigurations sensibili suin Bitwarden;
- aprireopening ilthe ticketDevOps versoticket; DevOps;
-updating aggiornare il file di tracciamentothe Move to Prod atracking rilasciofile completato.once deployment is complete.

2.2 DevOps team

The team responsible for installing or updating the service on remote machines.

##Responsibilities include:

receiving the microservice delivery or update ticket; retrieving Docker Compose files, .env files, and any required attachments; installing or updating the service on the specified VM; configuring any required DNS records; checking that the service has started correctly; communicating that the work is complete.

2.23 TeamRPA DevOpsgroup

The group that owns the process, best practices, and governance of RPA services.

ÈResponsibilities il team responsabile dell’installazione o aggiornamento del servizio sulle macchine remote.include:

Si

occupadefining di:technical

-standards;

riceveremaintaining ilshared ticketconventions; diensuring deliverydeployment otraceability; aggiornamentosharing microservizio;
-operational recuperareinformation, Dockersuch Compose,as fileavailable `.env`VMs, eenvironments, allegati necessari;
- installare o aggiornare il servizio sulla VM indicata;
- configurare eventualiand DNS richiesti;
-names. verificare che

---

il servizio sia avviato correttamente;
- comunicare il completamento della lavorazione.

## 2.3 Gruppo RPA

È il gruppo proprietario del processo, delle best practice e della governance dei servizi RPA.

Si occupa di:

- definire gli standard tecnici;
- mantenere le convenzioni comuni;
- garantire la tracciabilità dei rilasci;
- condividere informazioni operative, come VM disponibili, ambienti e DNS.

---

#

3. StrumentiTools utilizzatiused

##

3.1 GitLab

GitLab èis utilizzatoused per:to:

-

versionareversion ilsource codicecode; sorgente;
-manage gestirethe ilservice repositoryrepository; del servizio;
- eseguire eventuali pipelinerun CI/CD;
-CD pubblicarepipelines, immaginiwhere applicable; publish Docker nelimages registryto delthe repository;
-repository’s mantenereregistry; tracciabilitàmaintain ditraceability commit,of versionicommits, eversions, tag.and

##tags.

3.2 Docker eand Docker Compose

Docker èis utilizzatoused perto containerizzarecontainerize ilthe servizioRPA RPA.service.

Docker Compose èis utilizzatoused perto definiredefine l’esecuzionehow delthe servizioservice neiruns diversiin ambienti:the different environments:

-

locale;
-local; sviluppo;
-development; collaudo;
-acceptance produzione.testing;

##

production.

3.3 GitLab Container Registry

The repository’s GitLab registry contains the service’s Docker images.

IlThe registry GitLab delentire repository contieneis lenot immaginideployed Dockerto delremote servizio.environments. Instead, the following are used:

Negli

ambientithe remoti non viene rilasciato l’intero repository, ma vengono utilizzati:

- il fileenvironment’s Docker Compose dell’ambiente;
-file;

ilthe fileenvironment’s `.env`env dell’ambiente;
-file; l’immaginethe Docker giàimage pubblicataalready sulpublished to the registry;
- eventualiany fileexternal esternifiles nonnot inclusiincluded nell’immagine.in

##the image.

3.4 Bitwarden

Bitwarden èis utilizzatoused perto salvaresecurely estore condividereand share environment .env files.

The .env files must be stored in modo sicuro i file `.env` degli ambienti.

I file `.env` devono essere salvati nella raccoltathe RPA seguendocollection lausing the following naming convention:

```text

env_<ambienteenvironment>_<nome_automazioneautomation_name>

Examples:

```

env_dev_automation-name

Esempi:

env_coll_automation-name

```text
env_dev_nome-automazione
env_coll_nome-automazione
env_prod_nome-automazione

env_prod_automation-name

```

##

3.5 Sistema diDevOps ticketing DevOpssystem

IlThe sistema diDevOps ticketing DevOpssystem èis utilizzatoused perto richiedere:request:

-

• delivery diof nuovinew microservizi;
  -microservices;

aggiornamentoupdates dito microserviziexisting esistenti;
-microservices; modificachanges dito file.env `.env`;
-files; modificachanges dito Docker Compose;
-Compose caricamentofiles; diuploads fileof locali;
-local configurazionefiles; diDNS DNS;
-configuration; interventiwork sulleon VMremote remote.VMs.

##

3.6 File Move to Prod

Il file Move to Prod èfile il

The Move to Prod file condivisois usatothe pershared tracciarefile leused informazionito operativetrack deioperational rilasci.deployment information.

Contiene,Among traother lethings, altreit cose:contains:

-

disponibilitàVM delleavailability; VM;
-the ambienterelevant dienvironment; riferimento;
-the serviziodeployed rilasciato;
-service; the VM utilizzata;
-used; the DNS utilizzato;
-name eventualiused; noteany operative.operational notes.

IlThe file èis condivisoshared nelin canalethe Python group’s Teams del gruppo Python.channel.

---

---

#

4. Struttura attesa del repository

Prima di qualunque rilascio, ilExpected repository devestructure rispettare

Before leany deployment, the repository must comply with the RPA group’s Python and Docker best practice Python e Docker del gruppo RPA.practices.

##

4.1 StrutturaCode delstructure

codice

Application code must be located in the following folder:

src/

Il codice applicativo deve essere contenuto all’interno della cartella:Example:

```text
src/

repository/

```

Esempio:

```text
repository/
├── src/
│ └── ...
├── docker-compose.local.yml
├── docker-compose.dev.yml
├── docker-compose.coll.yml
├── docker-compose.prod.yml
├── .env.example
├── Dockerfile
├── pyproject.toml
└── README.md

```

##

4.2 Required Docker Compose richiestifiles

Devono essere presenti i Docker Compose relativifiles aglimust ambientibe previsti:provided for the planned environments:

```text

docker-compose.local.yml

docker-compose.dev.yml

docker-compose.coll.yml

docker-compose.prod.yml

```

LaThe naming convention puòmay esserebe adattataadapted aglito standardthe effettivigroup’s delactual gruppo,standards, mabut deveit esseremust coerentebe econsistent facilmenteand riconoscibile.easily recognizable.

##

4.3 Environment file

At least one example file must be provided, such as:

.env.example

The .env.example file must contain all variables required by the service, without any actual sensitive values.

Deve essere presente almeno un file di esempio, ad esempio:Example:

```text
.env.example

```

Il file `.env.example` deve contenere tutte le variabili necessarie al servizio, senza valori sensibili reali.

Esempio:

```env

APP_ENV=local

LOG_LEVEL=INFO

DB_HOST=

DB_PORT=

DB_NAME=

DB_USER=

DB_PASSWORD=

SECRET_KEY=

```

##

4.4 Volume mounts

Mount deipaths volumi

in

Ithe mount dei varivarious Docker Compose devonofiles partiremust dallabe cartellarelative correnteto delthe repository.current repository folder.

EsempioCorrect corretto:example:

```yaml

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

Example to avoid:

```

Esempio da evitare:

```yaml

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

Absolute local paths must not be used in Compose files intended for deployment, because they are not portable across environments and machines.

4.5 Docker images

Compose files for remote environments must not require building the code from the full repository.

```The remote environment must use images already published to the GitLab registry.

I path assoluti locali non devono essere usati nei Compose destinati al rilascio, perché non sono portabili tra ambienti e macchine diverse.Example:

## 4.5 Immagini Docker

Nei Compose degli ambienti remoti non deve essere necessario buildare il codice dal repository completo.

L’ambiente remoto deve usare immagini già pubblicate sul registry GitLab.

Esempio:

```yaml

services:
 
  automazione:
 
    image: registry.gitlab.com/gruppo/progetto/nome-servizio:dev-latest
 
    env_file:
 
      - .env

Alternatively, depending on the versioning strategy:

```

Oppure, in base alla strategia di versionamento:

```yaml

services:
 
  automazione:
 
    image: registry.gitlab.com/gruppo/progetto/nome-servizio:v1.2.3

```

##

4.6 Label per Continuous Delivery labels

If the service needs to support automatic updates through CD, the Compose file must include the labels required by the group’s standard.

SeThe illabels serviziomust deveenable esserethe aggiornabilesystem automaticamenteto tramite CD, il Compose deve includere le label previste dallo standard del gruppo.identify:

the service; the environment; the image to monitor; the update strategy.

LeIllustrative label devono permettere al sistema di riconoscere:example:

- servizio;
- ambiente;
- immagine da monitorare;
- strategia di aggiornamento.

Esempio indicativo:

```yaml

labels:
 
  - "rpa.cd.enabled=true"
 
  - "rpa.cd.environment=dev"
 
  - "rpa.cd.service=nome-automazione"

The actual labels must follow the standard defined by the RPA/DevOps group.

---

5. Differences between local and remote execution

5.1 Local execution

The entire repository is available locally.

```The developer can therefore:

run the code directly on the machine; modify the code; build the image; run the service using the local Compose file; mount local folders; perform full debugging.

The service can be tested locally in three ways:

running directly on the machine; running in Docker using the local Compose file; running in Docker using an environment-specific Compose file, such as dev.

5.2 Remote execution

The entire repository is not copied to the remote environment.

LeThe labelservice effettiveruns devono seguire lo standard definito dal gruppo RPA/DevOps.using:

---

#

the 5. Differenza tra esecuzione locale e ambiente remoto

## 5.1 Esecuzione locale

In locale è presente l’intero repository.

Lo sviluppatore può quindi:

- eseguire il codice direttamente sulla macchina;
- modificare il codice;
- buildare l’immagine;
- eseguire il servizio tramite Compose local;
- montare cartelle locali;
- fare debug completo.

In locale il servizio può essere testato in tre modalità:

1. esecuzione a crudo sulla macchina;
2. esecuzione Dockerizzata con Compose local;
3. esecuzione Dockerizzata con Compose di ambiente, ad esempio dev.

## 5.2 Esecuzione su ambiente remoto

Nell’ambiente remoto non viene copiato l’intero repository.

Il servizio viene eseguito usando:

-environment’s Docker Compose dell’ambiente;
-file;

filethe `environment’s .env`env dell’ambiente;
-file; immaginethe Docker pubblicataimage sulpublished to the GitLab Container Registry;
- eventualiany fileexternal esternifiles nonnot inclusiincluded nell’immagine.in the image.

This means the remote service must be self-sufficient using the image, Compose file, and configuration.

---

6. Deployment environments

Ideally, deployments progress through three environments:

development; acceptance testing; production.

6.1 Development

An environment used to check the service’s behavior in a remote, non-production setting.

QuestoIt significais cheused ilto serviziovalidate:

remoto

devethe essereDocker autosufficienteimage; Docker Compose; the .env configuration; connections to external systems; the service’s overall behavior.

6.2 Acceptance testing

An environment used for testing under conditions closer to production.

It is used to validate:

stability; more representative data and configurations; integrations; user testing or final functional testing.

6.3 Production

The final environment in which the service runs for operational use.

It requires greater attention to:

credentials; DNS; final configurations; VM availability; traceability; impact on users; rollback.

6.4 Skipping environments

Depending on urgency, criticality, or the nature of the development work, some steps may be skipped.

Examples:

deploying directly to acceptance testing; deploying directly to production; quickly deploying an urgent fix.

Skipping one or more environments must be a partiredeliberate daand immagine,justified Composedecision, ebecause configurazione.it reduces the level of progressive verification.

---

7. Preliminary phase: local validation

Before opening a deployment ticket, the developer must verify that the service works correctly locally.

7.1 Testing the service directly on the machine

The first test consists of running the service directly on the local machine.

---Objectives:

#

6.verify Ambientithat di rilascio

Idealmente i rilasci seguono tre ambienti:

1. sviluppo;
2. collaudo;
3. produzione.

## 6.1 Sviluppo

Ambiente usato per verificare il comportamento del servizio in un contesto remoto non produttivo.

Serve per validare:

- immagine Docker;
- Docker Compose;
- configurazione `.env`;
- connessioni verso sistemi esterni;
- comportamento generale del servizio.

## 6.2 Collaudo

Ambiente usato per test più vicini alla produzione.

Serve per validare:

- stabilità;
- dati e configurazioni più rappresentativi;
- integrazioni;
- test utente o test funzionali finali.

## 6.3 Produzione

Ambiente finale in cui il servizio viene eseguito per l’utilizzo operativo.

Richiede maggiore attenzione su:

- credenziali;
- DNS;
- configurazioni definitive;
- disponibilità della VM;
- tracciabilità;
- impatto sugli utenti;
- rollback.

## 6.4 Salto degli ambienti

In base a urgenza, criticità o caratteristiche dello sviluppo, alcuni step possono essere saltati.

Esempi:

- rilascio diretto in collaudo;
- rilascio diretto in produzione;
- aggiornamento rapido di una fix urgente.

Il salto di uno o più ambienti deve essere consapevole e motivato, perché riduce il livello di verifica progressiva.

---

# 7. Fase preliminare: validazione locale

Prima di aprire un ticket di rilascio, lo sviluppatore deve verificare che il servizio funzioni correttamente in locale.

## 7.1 Test del servizio a crudo

Il primo test consiste nell’eseguire il servizio direttamente sulla macchina locale.

Obiettivo:

- verificare che il codicethe Python funzioni;
-code verificareworks;

dipendenze;
-check verificaredependencies; configurazionicheck base;
-basic intercettareconfigurations; erroricatch applicativiapplication primaerrors dellabefore containerizzazione.containerization.

Example:

Esempio:

```bash

python -m src.main

Alternatively, depending on the project structure:

```

Oppure, in base alla struttura del progetto:

```bash

python src/main.py

7.2 Testing with the local Compose file

The second test consists of running the service using the local Compose file.

```Example:

## 7.2 Test con Compose local

Il secondo test consiste nell’eseguire il servizio tramite Compose local.

Esempio:

```bash

docker compose -f docker-compose.local.yml up --build

Objectives:

check the Dockerfile; check the image build; check local mounts; check environment variable handling; check ports and volumes; check containerized behavior.

7.3 Testing with an environment-specific Compose file

After testing the local Compose file, testing at least the dev Compose file is recommended.

```Example:

Obiettivo:

- verificare Dockerfile;
- verificare build dell’immagine;
- verificare mount locali;
- verificare gestione env;
- verificare porte e volumi;
- verificare comportamento containerizzato.

## 7.3 Test con Compose di ambiente

Dopo il Compose local, è consigliato testare almeno il Compose dev.

Esempio:

```bash

docker compose -f docker-compose.dev.yml --env-file .env.dev up

Objectives:

```

Obiettivo:

verify

-that verificarethe cheimage l’immagineis siacompatible compatibilewith conthe ilremote Compose remoto;
-file;

verificareverify chethat ilthe servizioservice nondoes dipendanot dadepend fileon presentifiles soloavailable nelonly repositoryin locale;
-the verificarelocal cherepository; leverify variabilithat sianothe sufficienti;
-variables simulareare ilsufficient; piùsimulate possibilethe ilremote comportamentomachine’s dellabehavior macchinaas remota.closely as possible.

---

8. Pre-deployment checklist

Before requesting deployment, verify that:

---

#

the 8.code Checklistis pre-rilasciolocated

Primain dithe richiederesrc/ ilfolder;

rilascio, verificare che:

- il codice sia contenuto nella cartella `src/`;
- siano presenti i Compose

local, dev, collaudoacceptance etesting, prod;
-and iprod Compose files are present; Compose mount deipaths are relative to the current folder; no absolute local paths are used; the Dockerfile is up to date; the image can be built; the service has been tested directly on the machine; the service has been tested with the local Compose partanofile; dallathe cartellaservice corrente;
-has nonbeen sianotested presentiwith pathat assolutileast locali;
-the il Dockerfile sia aggiornato;
- l’immagine sia buildabile;
- il servizio sia stato testato a crudo;
- il servizio sia stato testato condev Compose local;
-file; ilthe servizioenvironment’s sia stato testato almeno con Compose dev;
- il.env file `has been prepared; the .env` dell’ambiente sia stato preparato;
- ilenv file `.env`has nonnot siabeen committatocommitted nelto the repository;
- ilthe .env file `.env`has siabeen stato salvatostored in Bitwarden;
- l’immaginethe siaimage statahas pubblicatabeen sulpublished registryto GitLab;
-the ilGitLab registry; the Compose puntifile all’immaginereferences corretta;
-the sianocorrect presentiimage; eventualiany labelrequired CD richieste;
-labels sianoare statipresent; identificatiany eventualiexternal filefiles esternito daattach allegare;
-have siabeen stataidentified; individuatathe latarget VM dihas destinazionebeen dalselected filefrom the Move to Prod;
-Prod sianofile; statiany individuati eventualirequired DNS necessari.names have been identified.

---

9. Building and publishing the Docker image

The Docker image can be published in two ways:

through GitLab CI; manually from the developer’s local environment.

9.1 Building through CI

The preferred approach is an automatic build through a CI pipeline.

---The pipeline can be triggered by:

a push to a branch; a merge; a version tag; a specific commit; a manual workflow.

The image should have a clear tag.

# 9. Build e pubblicazione dell’immagine DockerExamples:

L’immagine Docker può essere pubblicata in due modalità:

1. tramite CI GitLab;
2. manualmente dall’ambiente locale dello sviluppatore.

## 9.1 Build tramite CI

La modalità preferibile è la build automatica tramite pipeline CI.

La pipeline può essere triggerata da:

- push su branch;
- merge;
- tag di versione;
- commit specifico;
- workflow manuale.

L’immagine dovrebbe essere taggata in modo chiaro.

Esempi:

```text

dev-latest

coll-latest

prod-latest

v1.2.3

commit-<sha>

A recommended strategy is to use both environment tags and immutable tags.

```Example:

Una strategia consigliata è avere sia tag ambientali sia tag immutabili.

Esempio:

```text

dev-latest

v1.2.3

commit-a1b2c3d

This way:

```

In

dev-latest questoenables modo:quick

-updates;

`dev-latest` permette aggiornamenti rapidi;
- `v1.2.3`3 permetteprovides tracciabilità;
-traceability; `commit-<sha>` permettesupports audittechnical tecnico.auditing.

9.2 Manual builds

Alternatively, the image can be built locally and pushed manually.

##Illustrative 9.2 Build manualeexample:

In alternativa, l’immagine può essere buildata localmente e pushata manualmente.

Esempio indicativo:

```bash

docker build -t registry.gitlab.com/gruppo/progetto/nome-servizio:dev-latest .

docker push registry.gitlab.com/gruppo/progetto/nome-servizio:dev-latest

Manual builds must be used with care, because they are less traceable than a CI pipeline.

---

10. Preparing the .env file

The environment’s .env file must be derived from the local file or the .env.example file.

```Each environment must have its own specific, independent variables.

La build manuale deve essere usata con attenzione, perché è meno tracciabile rispetto a una pipeline CI.

---

# 10. Preparazione del file `.env`

Il file `.env` dell’ambiente deve essere derivato dal file locale o dal file `.env.example`.

Ogni ambiente deve avere variabili specifiche e indipendenti.

##

10.1 VariabiliVariables dato renderemake specificheenvironment-specific

per

The ambientefollowing must differ between environments, where applicable:

user passwords; database passwords; secret keys; API tokens; connection strings; service credentials; endpoints; database names; buckets; application users; encryption keys; integration configurations.

Devono essere diverse per ogni ambiente, quando applicabile:Example:

- password utenti;
- password database;
- secret key;
- token API;
- connection string;
- credenziali di servizio;
- endpoint;
- nomi database;
- bucket;
- utenti applicativi;
- chiavi di cifratura;
- configurazioni di integrazione.

Esempio:

```env

APP_ENV=dev

LOG_LEVEL=INFO

DB_HOST=db-dev.internal
DB_PORT=5432
DB_NAME=automazione_dev
DB_USER=automazione_dev_user
DB_PASSWORD=<password-dev>

SECRET_KEY=<secret-dev>

```

##

10.2 SalvataggioStoring su Bitwarden

Al termine della preparazione, ilthe file `in Bitwarden

Once prepared, the .env`env devefile esseremust salvatobe stored in Bitwarden nellain raccoltathe RPA.RPA collection.

Naming convention:

```text

env_<ambienteenvironment>_<nome_automazioneautomation_name>

Examples:

env_dev_recupero-pratiche
env_coll_recupero-pratiche
env_prod_recupero-pratiche

```This allows anyone with authorization to:

Esempi:

```text
env_dev_recupero-pratiche
env_coll_recupero-pratiche
env_prod_recupero-pratiche

retrieve

```

the

Questoenvironment permetteconfiguration;

perform local debugging; check configurations; retrieve connection credentials; update the service in a chiunquecontrolled siamanner. autorizzato di:

- recuperare l’environment;
- eseguire debug locali;
- verificare configurazioni;
- recuperare credenziali di connessione;
- aggiornare il servizio in modo controllato.

##

10.3 CreazioneCreating dela Bitwarden Send

DopoAfter averstoring salvatothe il.env filefile, `.env`, è necessario creare un Bitwarden Send.

Il Send può contenere:

- il contenuto testuale del file `.env`;
- oppure direttamente il file `.env`.

Il link del Send dovrà essere allegato al ticket DevOps.

---

# 11. Apertura del ticket di delivery microservizio

Per richiedere un nuovo rilascio, aprire un ticket nel sistema DevOps.

## 11.1 Tipologia ticket

La tipologia da selezionare è:

```text
Delivery microservizio

```

Il ticket deve essere contestualizzato nell’ambiente RPA.

## 11.2 Ambiente remoto

Nel ticket deve essere specificato l’ambiente di rilascio:

- sviluppo;
- collaudo;
- produzione.

Deve inoltre essere indicata la destinazione:

- cloud;
- quartier generale;
- VM dedicata.

La VM deve essere scelta in base alla disponibilità riportata nel file Move to Prod, condiviso nel canale Teams del gruppo Python.

## 11.3 Informazioni da inserire nel ticket

Il ticket deve contenere almeno:

- nome del servizio;
- repository GitLab;
- ambiente target;
- VM target;
- Docker Compose da utilizzare;
- immagine Docker da utilizzare;
- tag immagine;
- linka Bitwarden Send delmust be created.

The Send can contain:

the text content of the .env file; or the .env file `.env`;
-itself. eventuali DNS

The richiesti;
-Send eventualilink filemust allegatibe daattached rilasciare;
-to eventualithe cartelleDevOps di destinazione dei file;
- eventuali note operative;
- eventuali dipendenze o prerequisiti.ticket.

##

---

11.4 FileOpening daa allegaremicroservice odelivery linkareticket

AlTo request a new deployment, open a ticket devonoin esserethe allegatiDevOps o referenziati:system.

11.1 Ticket type

-Select Dockerthe Composefollowing relativotype all’ambiente;
-(Microservice Bitwarden Send del file `.env`;
- eventuali Excel di supporto;
- eventuali shape file;
- eventuali file dati;
- eventuali template;
- eventuali configurazioni non incluse nell’immagine.delivery):

Delivery microservizio

IThe fileticket chemust nonbe risiedono nell’immagine Docker devono essere esplicitamente indicati, insieme al pathplaced in cuithe DevOpsRPA dovrà posizionarli.context.

Esempio:

11.2 Remote environment

```text
Allegare il file input_template.xlsx nella cartella ./data/templates/
Allegare gli shapefile nella cartella ./data/shapes/

```

---

# 12. DNS e pubblicazione esterna

Se il servizio richiede pubblicazione esterna, nelThe ticket devonomust esserespecify indicatithe ideployment DNS necessari.environment:

development; acceptance testing; production.

ComeIt bestmust practice,also ispecify DNSthe devono risiedere sotto i domini standard del gruppo.destination:

Per

sviluppocloud; eheadquarters; collaudo:dedicated VM.

```text
.rpa.collaudo-live.xyz

The

```

VM

Permust produzione:

be

```text
.rpa.eagleprojects.cloud

selected

```

based

Esempion indicativi:

the

```text
nome-servizio.rpa.collaudo-live.xyz
nome-servizio.rpa.eagleprojects.cloud

availability

```

shown

Lain naming convention effettiva deve essere coerente con gli standard del gruppo e approvata da DevOps.

---

# 13. Completamento del rilascio

Una volta che DevOps ha completato la lavorazione del ticket, lo sviluppatore deve verificare il servizio.

## 13.1 Verifiche post-rilascio

Verificare che:

- il container sia avviato;
- il servizio risponda correttamente;
- i log non presentino errori critici;
- le variabili ambiente siano corrette;
- eventuali file allegati siano presenti;
- eventuali DNS siano funzionanti;
- eventuali integrazioni siano operative;
- eventuali scheduler o job siano attivi;
- eventuali endpoint siano raggiungibili.

## 13.2 Aggiornamento del file Move to Prod

A rilascio completato, aggiornare il filethe Move to Prod nellefile, colonneshared previste.in the Python group’s Teams channel.

11.3 Information to include in the ticket

The ticket must contain at least:

service name; GitLab repository; target environment; target VM; Docker Compose file to use; Docker image to use; image tag; Bitwarden Send link for the .env file; any required DNS names; any attached files to deploy; any destination folders for those files; any operational notes; any dependencies or prerequisites.

11.4 Files to attach or link

The ticket must include attachments or references to:

the environment-specific Docker Compose file; the Bitwarden Send for the .env file; any supporting Excel files; any shapefiles; any data files; any templates; any configurations not included in the image.

Files that are not included in the Docker image must be explicitly identified, together with the path where DevOps must place them.

InserireExample:

almeno:

Attach the input_template.xlsx file for placement in ./data/templates/
Attach the shapefiles for placement in ./data/shapes/

---

12. DNS and external access

If the service requires external access, the required DNS names must be specified in the ticket.

-As nomea servizio;
-best ambiente;
- VM utilizzata;
-practice, DNS utilizzato;
-names repository;
-must eventualifall note;
-under datathe rilascio;
-group’s riferimentostandard ticketdomains.

For development and acceptance testing:

.rpa.collaudo-live.xyz

For production:

.rpa.eagleprojects.cloud

Illustrative examples:

nome-servizio.rpa.collaudo-live.xyz
nome-servizio.rpa.eagleprojects.cloud

The actual naming convention must be consistent with the group’s standards and approved by DevOps.

---

13. Completing deployment

IlOnce rilascioDevOps èhas consideratocompleted conclusothe solowork dopo:on the ticket, the developer must verify the service.

13.1 Post-deployment checks

1.Verify completamentothat:

ticket

DevOps;
2.the verificacontainer tecnicais delrunning; servizio;
3.the aggiornamentoservice delresponds filecorrectly; the logs contain no critical errors; the environment variables are correct; any attached files are present; any DNS names resolve correctly; any integrations are operational; any schedulers or jobs are active; any endpoints are reachable.

13.2 Updating the Move to Prod.Prod file

Once deployment is complete, update the appropriate columns in the Move to Prod file.

---Enter at least:

service name; environment; VM used; DNS name used; repository; any notes; deployment date; DevOps ticket reference.

#Deployment 14.is Aggiornamentoconsidered deicomplete servizionly esistentiafter:

Gli

aggiornamentithe possonoDevOps riguardare:ticket

-is immaginecompleted;

Docker;
-the service is technically verified; the Move to Prod file `.env`;
-is updated.

---

14. Updating existing services

Updates may involve:

the Docker image; the .env file; Docker Compose;
- filelocal locali;
-files; DNS;
- configurazioniadditional accessorie.configurations.

##

14.1 AggiornamentoUpdating immaginethe Docker image

SeIf ilthe servizioservice èhas statobeen configuratoconfigured conwith lethe corrette label dicorrect Continuous Delivery,Delivery l’aggiornamentolabels, dell’immaginethe puòimage avvenirecan automaticamente.be updated automatically.

In questothis casocase, èsimply sufficientepublish pubblicarethe ilnew nuovoimage tagunder `latest`the relativoenvironment’s all’ambiente.latest tag.

Esempi:Examples:

```text

dev-latest

coll-latest

prod-latest

```

Il sistema diThe CD rileveràsystem lawill nuovadetect immaginethe enew aggiorneràimage iland servizioupdate secondothe laservice configurazioneaccording prevista.to the configured settings.

##

14.2 AggiornamentoUpdating tramitethrough CI

Recommended approach:

Modalità

consigliata:modify

1.the modificarecode;

ilcommit codice;
2.the committare;
3.changes; pusharepush suto GitLab;
4. attenderewait buildfor dellathe pipeline;
5.pipeline verificarebuild; pubblicazioneverify immagine;
6.that verificarethe aggiornamentoimage automaticohas delbeen servizio;
7.published; controllareverify logthat ethe comportamentoservice applicativo.has

##been updated automatically;

check the logs and application behavior.

14.3 AggiornamentoUpdating manualethe immagineimage manually

For a manual build:

In caso di build manuale:

```bash

docker build -t registry.gitlab.com/gruppo/progetto/nome-servizio:dev-latest .

docker push registry.gitlab.com/gruppo/progetto/nome-servizio:dev-latest

After pushing, verify that the remote system has picked up the update.

```

---

15. Updating .env, Compose, or local files

DopoUpdates ilthat push,involve verificaremore chethan iljust sistema remoto abbia recepito l’aggiornamento.

---

# 15. Aggiornamento di `.env`, Compose o file locali

Gli aggiornamenti che non riguardano solamente l’immaginethe Docker devonoimage passaremust tramitego ticketthrough DevOps.a DevOps ticket.

##

15.1 TipologiaTicket tickettype

Use the following type (Microservice update):

La tipologia da usare è:

```text

Aggiornamento microservizio

```

##

15.2 InformazioniRequired richiesteinformation

Specify the following in the ticket:

Nel

ticketservice specificare:to

-update;

servizioaffected daenvironment; aggiornare;
-affected ambienteVM; interessato;
-requested VMchange; interessata;
-new modifica.env richiesta;
-file, nuovoif filerequired; `.env`, se necessario;
- linkupdated Bitwarden Send aggiornato;
-link; nuovonew Docker Compose,Compose sefile, necessario;
-if required; files to add or replace; destination path; any restart instructions; any checks to perform.

15.3 Updating the .env file

If the .env file da inserire o sostituire;
- path di destinazione;
- eventuali istruzioni di riavvio;
- eventuali verifiche da eseguire.changes:

##

15.3update Aggiornamentoits delcontents; filestore `.env`the

Senew cambia il file `.env`:

1. aggiornare il contenuto;
2. salvare la nuova versioneversion in Bitwarden;
3.

crearecreate una nuovonew Bitwarden Send;
4. allegareattach ilthe Send alto the ticket;
5. indicareclearly chiaramentestate chethat ilthe servizioservice devemust esserebe riavviato,restarted, seif necessario.necessary.

##

15.4 AggiornamentoUpdating delthe Compose file

SeIf cambia ilthe Docker Compose:Compose file changes:

1.

testaretest ilthe Compose localmente;
2.file verificarelocally; cheverify l’immaginethat esistathe sulimage exists in the registry;
3. allegareattach ilthe nuovonew Compose alfile to the ticket;
4. descriveredescribe lethe modifichemain principali;
5.changes; specificarespecify eventualiany impattiimpact suon volumi,volumes, porte,ports, labellabels, oor reti.networks.

##

15.5 AggiornamentoUpdating dilocal filefiles

locali

If local files need to be added or modified:

attach the files to the ticket; specify the destination path; state whether they replace existing files; state whether the service needs to be restarted.

Se devono essere aggiunti o modificati file locali:Example:

-

Replace allegare i file al ticket;
- indicare il path di destinazione;
- specificare se sostituiscono file esistenti;
- indicare se è necessario riavviare il servizio.

Esempio:

```text
Sostituire il filethe configurazione.xlsx nellafile cartellain ./data/config/
Aggiungere laAdd cartellathe ./data/shapes/ confolder ilwith contenutothe allegato
Riavviareattached ilcontents servizioRestart althe termineservice dellaonce copia

copying

```

is

---

complete

#

---

16. TemplateMicroservice delivery ticket Deliverytemplate

microservizio

Title:

```text
Titolo:
[DELIVERYMICROSERVICE MICROSERVIZIO]DELIVERY] <nome-servizioservice-name> - <ambienteenvironment>

Descrizione:
RichiedoDescription: ilI rilasciorequest deldeployment servizioof the RPA service <nome-servizioservice-name> sull’ambienteto the <dev/collaudo/acceptance testing/prod>.

Repositoryenvironment. GitLab:
GitLab repository: <repository link> repository>

Environment:

Ambiente:
<dev/collaudo/acceptance testing/prod>

Destinazione:
Destination: <cloud/quartier generale/VM dedicata>

VM target:
<nomeheadquarters/dedicated VM>

ImmagineTarget Docker:
VM: <VM name> Docker image: <registry/image:tag>

Docker Compose:
<allegatoattachment oor link>

File .env:
env file: <link Bitwarden Send link>

Required DNS richiesti:
names: <dnsrequired richiestiDNS oppurenames or N/A>

FileAdditional aggiuntivi:
files: <elencolist file,of pathfiles, didestination destinazione,paths, eventualiany notenotes>

NoteOperational operative:
notes: <eventualiany istruzionispecific specificheinstructions>

VerificheRequired richieste:
checks: - avviocontainer container
startup - verificalog log
check - verifica endpoint/scheduler/job
 check - verificaDNS DNS,check, seif presente

applicable

```

---

---

#

17. TemplateMicroservice update ticket Aggiornamentotemplate

microservizio

Title:

```text
Titolo:
[AGGIORNAMENTOMICROSERVICE MICROSERVIZIO]UPDATE] <nome-servizioservice-name> - <ambienteenvironment>

Descrizione:
RichiedoDescription: l’aggiornamentoI delrequest servizioan update to the RPA service <nome-servizioservice-name> sull’ambientein the <dev/collaudo/acceptance testing/prod>.

Servizio:
environment. Service: <nome-servizioservice-name>

Ambiente:
Environment: <dev/collaudo/acceptance testing/prod>

VM:
<nomeVM VMname>

TipoUpdate aggiornamento:
type: - immagineDocker Docker
image - .env file .env
- Docker Compose
- filelocal locali
files - DNS
- altro

other

DettaglioChange modifica:
details: <descrizionedetailed dettagliatadescription dellaof modificathe change>

NuovaNew immagineDocker Docker:
image: <registry/image:tag oppureor N/A>

Nuovo fileNew .env:
env file: <link Bitwarden Send oppurelink or N/A>

NuovoNew Docker Compose:
<allegato/attachment/link oppureor N/A>

FileFiles dato aggiungere/sostituire:
add/replace: <elencolist fileof efiles pathand didestination destinazionepaths oppureor N/A> Restart required: <yes/no> Operational notes: <any additional details>

---

18. Final deployment checklist

Before considering deployment complete, verify that:

Riavvio

richiesto:
<sì/no>the

Note operative:
<eventuali dettagli aggiuntivi>

```

---

# 18. Checklist finale rilascio

Prima di considerare concluso il rilascio, verificare:

-DevOps ticket DevOpsis completato;
-completed;

serviziothe avviato;
-service logis verificati;
-running; the logs have been checked; DNS funzionante,is seworking, previsto;
-if credenzialiapplicable; salvatecredentials correttamenteare correctly stored in Bitwarden;
- the .env file `.env`is nonnot presentepresent nelin the repository;
- the correct Compose correttofile sull’ambiente;
- immagine correttais in esecuzione;
-place filein esternithe presenti;
-environment; the correct image is running; external files are present; Move to Prod aggiornato;
-has eventualibeen stakeholderupdated; informati.any

---

relevant

#stakeholders have been informed.

---

19. RegolePractical praticherules dato ricordareremember

##

19.1 NonDo rilasciarenot codicedeploy nonuntested testatocode

Before deployment, the service must have been tested at least:

Prima

deldirectly rilascio,on ilthe serviziomachine; devewith esserethe statolocal testatoCompose almeno:file;

-

with the dev Compose file or a crudo;
- con Compose local;
-file conequivalent Composeto devthe oone Composeused equivalentein all’ambientethe remoto.remote

##environment.

19.2 NonDo committarenot filecommit `.env`env files

IActual file.env `.env`files realimust nonnot devonobe esserestored salvatiin nelthe repository.

NelThe repository devemust esserecontain presenteonly soloan unexample filefile, disuch esempio, come:as:

```text

.env.example

```

##

19.3 NonDo usarenot pathuse assolutiabsolute localilocal neipaths in Compose files

Mount paths must be relative to the current folder:

I mount devono partire dalla cartella corrente:

```yaml

./data:/app/data

They must not use absolute paths on the developer’s machine:

```

E non da path assoluti della macchina dello sviluppatore:

```yaml

/home/nomeutente/progetto/data:/app/data

```

##

19.4 NonDo dipenderenot daldepend on the full repository completo in remotoremotely

In ambientea remotoremote ilenvironment, serviziothe deveservice funzionaremust con:work with:

-

immagine Docker;
-the Docker image; Docker Compose;
- filethe `.env`;
-env filefile; esternithe dichiarati.declared

##external files.

19.5 AggiornareAlways sempreupdate Move to Prod

Il fileThe Move to Prod èfile necessariois perrequired mantenereto tracciabilitàmaintain operativaoperational deitraceability serviziof rilasciati.deployed services.

OgniEvery rilasciodeployment oor variazionesignificant significativachange devemust esserebe riportatarecorded nelin the file.

---

---

#

20. FlussoProcess sinteticooverview

##

New Nuovodeployment

rilascio

Develop 

```text
Sviluppothe codice
code ↓
Validazione Validate the repository
↓
Test adirectly crudo
on the machine ↓
Test the local Compose local
file ↓
Test Composethe dev/coll/prod
 Compose file ↓
Build immagine
the image ↓
Push immaginethe suimage to the GitLab Registry
↓
Preparazione filePrepare the environment’s .env ambiente
file ↓
Salvataggio Store the .env sufile in Bitwarden
↓
Creazione Create a Bitwarden Send
↓
Scelta Select a VM da Move to Prod
↓
Apertura ticket Delivery microservizio
↓
Lavorazione DevOps
↓
Verifica servizio
↓
Aggiornamento Move to Prod
↓
Rilascio concluso

```

## Aggiornamento servizio

```text
Modifica codice/configurazione
↓
Test locale
↓
Se cambia solo immagine:
    push nuovo tag latest ambiente
    verifica aggiornamento automatico CD
↓
Se cambiano env/compose/file:
    aggiornamento Bitwarden se necessario
    apertura ticket Aggiornamento microservizio
    lavorazione DevOps
↓
Verifica servizio
↓
Aggiornamentofrom Move to Prod se↓ necessario

Open

```./

a microservice delivery ticket ↓ DevOps performs the work ↓ Verify the service ↓ Update Move to Prod ↓ Deployment complete

Service update

Modify the code/configuration
↓
Test locally
↓
If only the image changes:
    push the new image under the environment’s latest tag
    verify the automatic CD update
↓
If env/compose/files change:
    update Bitwarden if necessary
    open a microservice update ticket
    DevOps performs the work
↓
Verify the service
↓
Update Move to Prod if necessary