Passo 11: Creare branch del codice

5.0 version
Maintained

Creare branch del codice

Esistono molti modi per organizzare il flusso di lavoro per modificare il codice di un progetto, ma lavorare sul branch master ed effettuare un deploy direttamente in produzione del codice senza una suite di test, probabilmente, non è la scelta migliore.

Testare l’applicazione non riguarda solo i test unitari o funzionali, ma anche il controllo del comportamento dell’applicazione con i dati di produzione. Se voi o i vostri stakeholder potete utilizzare l’applicazione esattamente come sarà distribuita agli utenti finali, questo sarà un enorme vantaggio e vi permetterà di effettuare deploy con più sicurezza. Mettere in condizione delle persone non tecniche di validare le nuove funzionalità è un concetto importantissimo.

Per semplicità e per evitare di ripeterci continueremo a lavorare nel branch master, ma più avanti vedremo come migliorare questo aspetto.

Adottare un flusso di lavoro con git

Un possibile flusso di lavoro potrebbe essere quello di creare un branch per ogni nuova funzionalità o la risoluzione di un bug. Quest’approccio è semplice ed efficiente.

Descrivere l’infrastruttura

Forse non ve ne siete ancora accorti, ma avere l’infrastruttura salvata su file insieme al codice aiuta molto. Docker e SymfonyCloud usano i file di configurazione per descrivere l’infrastruttura del progetto. Quando una nuova funzionalità necessita di un servizio aggiuntivo, i cambiamenti al codice e all’infrastruttura saranno presenti nello stesso blocco di modifiche.

Creazione di branch

Il flusso di lavoro inizia con la creazione di un nuovo branch git:

1
$ git branch -D sessions-in-redis || true
1
$ git checkout -b sessions-in-redis

Questo comando crea un nuovo branch dal nome sessions-in-redis partendo dal branch master. Sarà una «biforcazione» del codice e della configurazione dell’infrastruttura.

Salvare le sessioni su Redis

Come probabilmente avrete intuito dal nome del branch, vogliamo cambiare il salvataggio delle sessioni, togliendole dal filesystem per memorizzarle su Redis.

I passi necessari per fare questo sono semplicemente:

  1. Creare un branch git;
  2. Aggiornare la configurazione di Symfony, se necessario;
  3. Aggiungere e/o modificare qualche linea di codice se necessario;
  4. Aggiornare la configurazione di PHP (aggiungendo l’estensione Redis per PHP);
  5. Aggiornare l’infrastruttura su Docker e SymfonyCloud (aggiungendo il servizio Redis);
  6. Testare nel nostro ambiente in locale;
  7. Effettuare dei test anche da remoto;
  8. Effettuare un merge del branch su master;
  9. Deploy in produzione;
  10. Cancellare il branch.

Tutte le modifiche dal punto 2 al punto 5 possono essere fatte in un unico blocco di modifiche:

patch_file
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
--- a/.symfony.cloud.yaml
+++ b/.symfony.cloud.yaml
@@ -15,8 +15,13 @@ runtime:
 build:
     flavor: none

+variables:
+    php-ext:
+        redis: 5.3.1
+
 relationships:
     database: "db:postgresql"
+    redis: "rediscache:redis"

 web:
     locations:
--- a/.symfony/services.yaml
+++ b/.symfony/services.yaml
@@ -2,3 +2,6 @@ db:
     type: postgresql:11
     disk: 1024
     size: S
+
+rediscache:
+    type: redis:5.0
--- a/config/packages/framework.yaml
+++ b/config/packages/framework.yaml
@@ -7,7 +7,7 @@ framework:
     # Enables session support. Note that the session will ONLY be started if you read or write from it.
     # Remove or comment this section to explicitly disable session support.
     session:
-        handler_id: null
+        handler_id: '%env(REDIS_URL)%'
         cookie_secure: auto
         cookie_samesite: lax

--- a/docker-compose.yaml
+++ b/docker-compose.yaml
@@ -8,3 +8,7 @@ services:
             POSTGRES_PASSWORD: main
             POSTGRES_DB: main
         ports: [5432]
+
+    redis:
+        image: redis:5-alpine
+        ports: [6379]

Non è bellissimo?

«Riavviare» docker per avviare il servizio Redis:

1
2
$ docker-compose stop
$ docker-compose up -d

Guardiamo il sito locale. Poiché non ci sono cambiamenti visivi e poiché non stiamo ancora usando le sessioni, dovrebbe funzionare tutto come prima.

Deploy di un branch

Prima di passare al deploy in produzione, dovremmo testare il branch su un’infrastruttura identica a quella di produzione. Dovremmo anche controllare che tutto funzioni bene sull’ambiente Symfony prod (il sito locale usava l’ambiente Symfony dev).

Prima di tutto, assicuriamoci di aver fatto commit di tutti i cambiamenti sul nuovo branch:

1
2
$ git add .
$ git commit -m'Configure redis sessions'

Ora, creiamo un ambiente SymfonyCloud a partire dal branch:

1
$ symfony env:delete sessions-in-redis --no-interaction
1
$ symfony env:create

Con il seguente comando creeremo un nuovo ambiente:

  • Il branch eredita il codice e l’infrastruttura dall’attuale branch (sessions-in-redis);
  • I dati provengono dall’ambiente master (ovvero dalla produzione) prendendo un’istantanea coerente di tutti i dati come i file (quelli caricati dagli utenti, per esempio) e i database;
  • Viene creato un nuovo cluster dedicato per effettuare il deploy del codice, per i dati e per l’infrastruttura.

Poiché il deploy segue gli stessi passi del deploy in produzione, verranno eseguite anche le migrazioni del database. Questo è un ottimo modo per convalidare che le migrazioni funzionino con i dati di produzione.

Gli ambienti differenti da master sono molto simili a quello master, a eccezione di alcune piccole differenze: ad esempio, per impostazione predefinita, le email non vengono inviate.

Una volta completato il deploy, apriamo col browser l’URL inerente al nuovo branch:

1
$ symfony open:remote

Si noti che tutti i comandi di SymfonyCloud funzionano sul branch corrente. Il deploy del branch sessions-in-redis metterà a disposizione un URL simile a https://sessions-in-redis-xxx.eu.s5y.io/, che si potrà aprire con questo comando.

Testiamo il sito su questo nuovo ambiente, dovremmo vedere tutti i dati che abbiamo creato nell’ambiente master.

Se aggiungiamo altre conferenze sull’ambiente master, non le visualizzeremo nell’ambiente sessions-in-redis e viceversa. Gli ambienti sono indipendenti e isolati.

Se il codice di master si evolve, possiamo sempre fare un rebase del branch, risolvendo eventuali conflitti sia sul codice sia sull’infrastruttura, ed effettuare un deploy della versione aggiornata.

Possiamo anche sincronizzare i dati dell’ambiente master con quello di sessions-in-redis:

1
$ symfony env:sync

Effettuare il debug del deploy di produzione prima del deploy effettivo

Per impostazione predefinita, tutti gli ambienti SymfonyCloud usano le stesse impostazioni dell’ambiente master ovvero l’ambiente Symfony prod. Questo ci permette di testare l’applicazione in condizioni reali. Ci dà la sensazione di sviluppare e testare direttamente sui server di produzione, ma senza i rischi associati. Questo mi ricorda i bei vecchi tempi dei deploy via FTP.

In caso di problemi, si potrebbe voler passare all’ambiente dev di Symfony:

1
$ symfony env:debug

Una volta che risulta tutto funzionante, torniamo alle impostazioni di produzione:

1
$ symfony env:debug --off

Avvertimento

Non abilitare mai l’ambiente dev e non abilitare mai il Profiler di Symfony sul branch master; renderebbe l’applicazione davvero lenta ed esporrebbe vulnerabilità di sicurezza molto gravi.

Verifichiamo il deploy di produzione prima del vero e proprio deploy

La possibilità di poter visionare in anteprima la prossima versione del sito web con i dati di produzione apre molte opportunità: dai test di regressione visiva ai test sulle prestazioni. Blackfire è lo strumento perfetto per fare questo tipo di lavoro.

Fare riferimento alla sezione sulle «Prestazioni» per saperne di più su come utilizzare Blackfire per testare il codice prima del deploy.

Merge su produzione

Quando siamo soddisfatti dei cambiamenti effettuati sul branch, effettuiamo il merge del codice e dell’infrastruttura sul branch master:

1
2
$ git checkout master
$ git merge sessions-in-redis

E ora effettuiamo il deploy:

1
$ symfony deploy

Quando effettuiamo un deploy, solo il codice e le modifiche all’infrastruttura vengono inviate su SymfonyCloud; i dati non vengono alterati in alcun modo.

Fare pulizia

Infine, facciamo pulizia rimuovendo il branch e l’ambiente SymfonyCloud:

1
2
$ git branch -d sessions-in-redis
$ symfony env:delete --env=sessions-in-redis --no-interaction

  • « Previous Passo 10: Costruire l’interfaccia utente
  • Next » Passo 12: Ascolto degli eventi

This work, including the code samples, is licensed under a Creative Commons BY-NC-SA 4.0 license.