Magento 2 Source Code Beheer met Git en Bitbucket

In deze blog beschrijf ik hoe we ons source code-beheer hebben opgezet met Git en Bitbucket.

Click here for the English version.

Onze Wensen

Dit was voor ons van belang voor source code-beheer:

• Versiebeheer
• Backup
• Online toegang tot alle code en revisies
• Volledige toezicht op toegang tot de code
• Snelheid

Onderdelen van de Oplossing

Deze onderdelen speelden een rol in onze oplossing:

• Onderscheid tussen ontwikkel-omgeving en productie-omgeving
• SSH: developer keys en deployment keys
• Shop-repositories en extensie-repositories

De Hosting Service

Git kiezen voor source code-beheer ligt voor de hand vandaag de dag. Omdat het een gedistribueerd versiebeheersysteem is, zorgt het ervoor dat de volledige repository gekopieerd wordt naar alle plaatsen waar het in gebruik is. De source code is dus veilig. Het volledige doorgronden van Git kost veel tijd, maar het dagelijks gebruik ervan is makkelijk te leren.

Github en Bitbucket zijn de meest gebruikte online source code-beheer-partijen. Github is het meest populair van de twee voor publiek toegankelijke source code, maar onze source code moet afgeschermd blijven. Bitbucket biedt gratis toegang tot ongelimiteerde publieke en privé repositories voor 5 gebruikers. Het is snel en biedt een nuttige gebruikersinterface. We zijn erg blij met Bitbucket 🙂

Twee Typen Repositories

We maken een aparte repository voor elke shop. Deze repository leunt zwaar op zijn .gitignore file. Dit eenvoudige bestand bepaalt welke bestanden daadwerkelijk plaats nemen in de repository. We volgen  de aanbevelingen van Alan Kent in deze. Met name de vendor map wordt uitgesloten van de repository. Deze omvat de Magento 2 core, zijn dependencies, en alle publieke third-party extensies.

De shop repository bevat ons shop-specifieke maatwerk, die zich bevindt in app/code en app/design. Ook de betaalde third-party extensies die de shop gebruikt, worden hierin opgeslagen.

Naast deze shop repositories ontwikkelen we ook gedeelde extensies die we gebruiken in meerdere shops. Elk van deze extensies krijgt zijn eigen repository en wordt beheerd door Composer, net als de publieke third-party extensies.

Bij elkaar bestaat de shop uit de hoofd-repository en nul of meer eigen extensies. Deze extensies leven in de vendor directory en ieder van hen heeft een eigen git checkout.

Composer

Onze extensies worden beheerd met composer, net als de andere third-party extensies. Om een extensie aan een shop toe te voegen, voegen we een paar regels toe aan de repositories sectie van composer.json:

Dit vertelt Composer onze Git repository toe te voegen aan zijn lijst met Composer repositories, de plaatsen waar het zoekt naar packages.

Vervolgens vertellen we Composer om onze extensie toe te voegen. Als de extensie nog in ontwikkeling is, zoals zo vaak het geval, moeten we de @dev stability flag toevoegen. Dit vertelt Composer dat het zijn minimum stability requirement voor deze extension moet verlagen. [1]

Uiteindelijk activeren we de extensie in Magento

Zodra een extension stable is geworden, kunnen we een repository taggen, met het commando “git tag”, en deze tag gebruiken in plaats van de @dev vlag.

SSH Toegang voor Ontwikkelaars: Developer Keys

Git repositories worden vaak gesynct met HTTPS of SSH. HTTPS gebruikt een gebruikersnaam/wachtwoord-combinatie, terwijl SSH werkt met public/private keys. SSH bleek flexibeler en veiliger voor ons.

Elke ontwikkelaar heeft een developer key in Bitbucket die beheerd kan worden in zijn account. Dit is zijn public SSH key. Het is ook mogelijk om meerdere keys te hebben, een voor elke ontwikkel-omgeving, bijvoorbeeld.

Een SSH key (private en public) wordt gegenereerd met het commando “ssh-keygen” op Linux machines. Bitbucket beveiligt de verbinding door de developer key (the public key op Bitbucket) aan de private key op de ontwikkel-machine te koppelen.

We plaatsen alle ontwikkelaars in een enkel team, en alle projecten/repositories hebben dit team als eigenaar. Op deze manier hebben alle ontwikkelaars van het team toegang (lezen/schrijven) tot alle repositories.

SSH Access op Productie: Deployment Keys

Een shop in productie heeft één enkele gebruiker die source code updates beheert. Deze gebruiker zou de repositories alleen moeten kunnen lezen van Bitbucket. En het is belangrijk voor ons dat deze gebruiker alleen toegang heeft tot precies de repositories die we willen.

Bitbucket, evenals Github, heeft hier een constructie voor die deployment key heet. Een deployment key is een public SSH key, evenals de developer key, maar het is alleen toegekend aan specifieke repositories, en het mag alleen to lezen, niet schrijven. We kunnen bepalen welke shop / gebruiker toegang heeft tot elk van onze extensies via the Bitbucket interface.

Conclusion

De combinatie van Git en Bitbucket biedt ons de controle over de source code die we nodig hebben. SSH maakt het makkelijk om ermee te werken en geeft ons het toegangsbeheer dat we willen.