Branching van de code

Het eigen maken van een Git Workflow

Een mogelijke workflow is het creëren van een branch per nieuwe functie of bugfix. Dit is eenvoudig en efficiënt.

Branches maken

De workflow begint met het aanmaken van een Git branch:

1

$ git branch -D sessions-in-db || true

1

$ git checkout -b sessions-in-db

Dit commando maakt een sessions-in-db branch aan vanuit de master branch. Het maakt een afsplitsing van de code en de infrastructuurconfiguratie.

Sessies opslaan in de database

Zoals je misschien - op basis van de branchnaam - geraden hebt, willen we de session-storage overschakelen van het filesystem naar een database (in dit geval onze PostgreSQL database).

De stappen die nodig zijn om het te realiseren zijn logisch:

1. Maak een Git branch aan;
2. Werk de Symfony-configuratie bij indien nodig;
3. Schrijf en/of update wat code indien nodig;
4. Update the PHP configuration if needed (like adding the PostgreSQL PHP extension);
5. Update de infrastructuur op Docker en Upsun indien nodig (voeg bijvoorbeeld de PostgreSQL-service toe);
6. Lokaal testen;
7. Remote testen;
8. Merge de branch met de master branch;
9. Deployen naar productie;
10. Verwijder de branch.

Verander de session.handler_id configuratie en verwijs naar de database DSN om sessies in de database op te slaan:

1
2
3
4
5
6
7
8
9
10
11
12

--- i/config/packages/framework.yaml
+++ w/config/packages/framework.yaml
@@ -3,7 +3,8 @@ framework:
     secret: '%env(APP_SECRET)%'

     # Note that the session will be started ONLY if you read or write from it.
-    session: true
+    session:
+        handler_id: '%env(resolve:DATABASE_URL)%'

     #esi: true
     #fragments: true

We moeten een sessions tabel toevoegen om de gegevens in de database op te slaan. Dit doen we middels een Doctrine migratie:

1

$ symfony console make:migration

Migreer de database:

1

$ symfony console doctrine:migrations:migrate

Test lokaal door naar de website te surfen. Omdat er geen visuele veranderingen zijn en omdat we nog geen sessies gebruiken, zou alles nog steeds moeten werken zoals voorheen.

Commit je wijzigingen in de nieuwe branch:

1
2

$ git add .
$ git commit -m'Configure database sessions'

Deployen van een branch

Voordat we de branch in productie nemen, moeten we deze testen op dezelfde infrastructuur als in productie. We moeten ook valideren dat alles goed werkt voor de prod Symfony-omgeving (de lokale website gebruikt de dev Symfony-omgeving).

Laten we nu een Upsun-omgeving maken op basis van de Git branch:

1

$ symfony cloud:env:delete sessions-in-db

1

$ symfony cloud:push

Dit commando creëert vervolgens een nieuwe omgeving:

• De branch erft de code en infrastructuur van de huidige Git branch (sessions-in-db);
• De gegevens komen uit de master- (aka-productie) omgeving door het maken van een consistente snapshot van alle service-gegevens, inclusief bestanden (bijvoorbeeld door de gebruiker geüploade bestanden) en databases;
• Er wordt een nieuw dedicated cluster gecreëerd om de code, de gegevens en de infrastructuur te deployen.

Aangezien de deployment dezelfde stappen volgt als de deployment naar productie, zullen ook databasemigraties worden uitgevoerd. Dit is een goede manier om te valideren dat de migraties werken met de productiedataset.

De niet-master omgevingen lijken erg op de master omgeving, op enkele kleine verschillen na: e-mails worden bijvoorbeeld standaard niet verstuurd.

Zodra de deployment is voltooid, open je de nieuwe branch in een browser:

1

$ symfony cloud:url -1

Merk op dat alle Upsun commando's werken op de huidige Git branch. Dit commando opent de gedeployede URL voor de sessions-in-db branch; de URL ziet er dan als volgt uit https://sessions-in-db-xxx.eu-5.platformsh.site/.

Test de website op deze nieuwe omgeving, je zou alle gegevens moeten zien die je in de master-omgeving hebt aangemaakt.

Als je meer conferenties aan de master omgeving toevoegt, dan zullen ze niet in de sessions-in-db omgeving verschijnen en vice versa. De omgevingen zijn onafhankelijk en geïsoleerd.

Als de code op master evolueert, kun je altijd de Git branch rebasen en de bijgewerkte versie deployen, waardoor de conflicten voor zowel de code als de infrastructuur worden opgelost.

Je kan zelfs de gegevens van de master terug naar de sessions-in-db omgeving synchroniseren:

1

$ symfony cloud:env:sync

Het debuggen van productie-deployment vóór de ingebruikname

Standaard gebruiken alle Upsun-omgevingen dezelfde instellingen als de master / prod omgeving (ook wel de Symfony prod omgeving genoemd). Dit stelt je in staat om de toepassing in reële omstandigheden te testen. Het geeft je het gevoel dat je direct op productieservers ontwikkelt en test, maar zonder de risico's die daarmee gepaard gaan. Dit doet me denken aan de goede oude tijd toen we deployments via FTP verzorgden.

In het geval van een probleem, kan je misschien overstappen naar de Symfony dev omgeving:

1

$ symfony cloud:env:debug

Als je klaar bent, ga dan terug naar de productie-instellingen:

1

$ symfony cloud:env:debug --off

Testen van de productie-deployments voor de ingebruikname

Toegang hebben tot de toekomstige versie van de website met productiegegevens biedt veel mogelijkheden: van visuele regressietests tot performance tests. Blackfire is de perfecte tool voor de klus.

Raadpleeg de stap over Prestaties om meer te weten te komen over hoe je Blackfire kan gebruiken om jouw code te testen voordat je deze deployt.

Mergen naar productie

Als je tevreden bent met de wijzigingen in de branch, merge dan de code en de infrastructuur naar de Git master branch:

1
2

$ git checkout master
$ git merge sessions-in-db

En deploy:

1

$ symfony cloud:push

Bij de deployment worden enkel de code en wijzigingen in de infrastructuur naar Upsun gepusht; de data wordt op geen enkele wijze beïnvloed.

Opruimen

Ruim tot slot op door de Git branch en de Upsun omgeving te verwijderen:

1
2

$ git branch -d sessions-in-db
$ symfony cloud:env:delete -e sessions-in-db