Een van de grootste dingen van WordPress is hoe gemakkelijk het te gebruiken is. Aan de andere kant voelen veel gebruikers vanwege deze eenvoud niet de drang om uit hun comfortzone te stappen en nieuwe dingen te leren. Deployment-automatisering is vaak een van die dingen die worden weggelaten.
In dit artikel leg ik uit waarom het de moeite waard is om er wat tijd in te steken om je leven (op de lange termijn) eenvoudiger te maken. We gebruiken de maatje CI/CD-toepassing terwijl we dit proces doorlopen.
Waarom u uw implementaties zou moeten automatiseren
We zijn ook maar mensen en dit betekent dat we fouten maken. En elke keer dat we hetzelfde doen, is er een grotere kans dat we iets missen.
Aan de andere kant houden machines ervan om dingen te herhalen en, indien correct geprogrammeerd, zullen ze uw implementatieautomatisering elke keer perfect kunnen uitvoeren.
Dankzij automatisering raak je niet alleen van een monotone en repetitieve taak af, maar weet je ook zeker dat het elke keer hetzelfde werkt.
Voordat je start
Allereerst moet je git gebruiken om al je code op te slaan. Waarom? Dat is eenvoudig – met git kun je eenvoudig al je codewijzigingen beheren. Het is ook de basis van teamwork.
Ik kan me geen team voorstellen dat geen versiebeheersysteem gebruikt.
Het helpt je ook om aan meerdere functies tegelijk te werken (dankzij branches) en stelt je in staat om conflicten in je code op te lossen (wanneer twee ontwikkelaars aan hetzelfde bestand werkten).
Maak je geen zorgen als je niet graag met een CLI werkt – er zijn veel geweldige GUI git-tools, zoals GitKraken of Git toren.
U hebt ook een CI/CD-toepassing nodig. In dit artikel gebruik ik Buddy CI/CD. Waarom? Er zijn twee hoofdredenen:
- Het is heel gemakkelijk te gebruiken, vanwege de gebruikersinterface.
- Er zijn meer dan 150 vooraf geconfigureerde acties.
Het heeft een gratis niveau, dus u hoeft in het begin geen extra geld te investeren. Natuurlijk, maatje is niet de enige toepassing als deze. U kunt ook GitHub Actions, GitLab CI, Branch CI of een van de vele andere gebruiken.
Code opslaan in Git
Nu moet u de juiste strategie bepalen voor het opslaan van uw code.
Over het algemeen moet u beslissen wat u in uw repository wilt opslaan. Als u alle aangepaste code in uw thema opslaat, zou het thema het enige in uw repository moeten zijn.
Als je werkt met code in thema, plug-ins en zelfs mu-plug-ins, is het een goed idee om de map wp-content op te slaan (zonder de map uploads).
Gaan hier om een van de beste .gitignore-bestanden te vinden die je zou moeten gebruiken. Als u een meer gevorderde gebruiker bent, kunt u overwegen om Composer-gebaseerd beheer te gebruiken, vergelijkbaar met het beheer dat wordt gebruikt in gesteente.
In dit artikel zal ik me alleen concentreren op het eerste geval, maar ik raad aan om dieper in alle benaderingen te duiken. Op een gegeven moment ga je ze allemaal gebruiken.
Buddy instellen
Nadat je onze code naar onze Git-repository hebt gepusht, moet je een account maken op Buddy’s website of inloggen als je die al hebt.
Klik eerst op de Project maken knop.
Selecteer vervolgens uw Git-repository.
Dus op dit punt is uw repository verbonden. Nu is het tijd om uw eerste pijplijn te maken. Een pijplijn is niets anders dan een reeks acties die worden uitgevoerd telkens wanneer aan een triggervoorwaarde wordt voldaan.
Naast het instellen van een naam, moeten we ook een trigger selecteren. Bij een gebeurtenis kunnen we een pijplijn instellen die elke keer wordt uitgevoerd als we iets naar een geselecteerde vertakking pushen. Handmatig wordt de pijplijn pas uitgevoerd nadat u op de knop hebt geklikt. Op schema loopt de pijplijn bijvoorbeeld één keer per dag of één keer per week
Kies nu handmatig.
En dat is alles – u hebt alles ingesteld. Tijd om te beginnen met implementeren.
Het eenvoudigste geval
Laten we het eenvoudigste geval maken waarin u alle wijzigingen op uw server kopieert.
In de lijst met acties ziet u meer dan 150 acties, maar u hebt alleen de acties nodig uit de Overdracht tabblad nu:
De beste manier om bestanden over te zetten op uw GoDaddy-hosting is om SFTP te gebruiken.
U moet alle inloggegevens invullen en de juiste . doorgeven Extern pad naar uw map wp-content/themes (omdat we alleen het thema implementeren).
Vergeet niet om bestanden uit te sluiten die u niet wilt implementeren in de Negeer paden tabblad.
Dus elke keer dat u op de drukt Rennen knop, worden alle door u aangebrachte wijzigingen geïmplementeerd.
Cool toch? Nou, niet helemaal.
Ik bedoel, het deel waarin alle wijzigingen met één klik naar productie worden gepusht, is echt gaaf. Veel beter dan het te doen met Filezilla.
Maar er zijn enkele nadelen: u moet in het Buddy-paneel wachten om te zien wanneer de implementatie is voltooid en u moet handmatig controleren of uw site nog werkt
Laten we het oplossen door twee extra acties toe te voegen.
Laten we eerst de . toevoegen Website-bewaking. Na de implementatie wordt gecontroleerd of onze website nog werkt. De configuratie is heel eenvoudig en vereist alleen het doorgeven van de URL van de website.
Op dit moment zou uw pijplijn er als volgt uit moeten zien:
De volgende stap is het toevoegen van een melding in de Bij mislukking tabblad (dit betekent dat die acties alleen worden uitgevoerd als er iets is mislukt). U kunt een van de vele manieren kiezen om een melding te verzenden, waaronder e-mail, Slack, Telegram, Discord, Microsoft Teams en sms.
In dit voorbeeld zal ik een toevoegen e-mail actie. Ga naar de Bij mislukking tabblad, klik op Actie toevoegenen selecteer E-mail van de lijst. De configuratie is vrij eenvoudig. Voer gewoon de titel, inhoud en de lijst met ontvangers in:
Nu is uw implementatiestroom een beetje beter. U hoeft niet te wachten en handmatig te controleren of uw website nog werkt en als er iets misgaat, krijgt u hierover een e-mail (of een andere melding).
Maar we kunnen beter.
Profiteren van een staging-server
Hoewel het proces werkt en zelfs controleert of uw website nog in leven is, heeft het één grote fout: we implementeren eerst in productie en controleren later of alles in orde is. Als dat niet het geval is, werkt uw website nog steeds niet totdat u het probleem hebt opgelost.
Gebruik daarom een staging-server. Het is heel eenvoudig om er een te gebruiken op GoDaddyvolg gewoon deze tutorial.
Dankzij de staging-server implementeert u eerst de wijzigingen daar, controleert u of uw website nog werkt en zo ja, implementeert u deze in productie.
Deze kleine wijziging zorgt ervoor dat als je een fatale fout hebt, deze niet wordt vrijgegeven voor je productie.
Netjes toch? Dit is ook het moment waarop u zult zien hoe implementatieautomatisering tijd bespaart. Als u dit handmatig zou doen, zou u wijzigingen op twee servers moeten implementeren.
Na het toevoegen van de extra implementatiestap zou uw pijplijn er als volgt uit moeten zien:
Ik heb de extra stap toegevoegd om ook te controleren of de productiewebsite nog werkt. Hoewel het zou moeten, is er altijd een kans dat we de PHP-versie alleen bij productie hebben gewijzigd of dat we iets buiten git hebben gewijzigd.
Automatisering van implementaties verbeteren
Ik heb je zojuist het meest elementaire implementatie-automatiseringsscenario met de eenvoudigste test laten zien, maar op basis hiervan kun je het beter maken.
Er zijn drie manieren om uw implementaties beter te maken:
- Gebruik de pijplijn om uw activa te beheren en te bouwen met behulp van npm en Componist.
- Voeg meer tests toe, beginnend met linters en eindigend met een volledige teststack met unit-, integratie- en end-to-end-tests.
- Gebruik geavanceerdere implementatiemethoden, zodat u implementaties zonder downtime kunt realiseren.
Zodra u de automatisering van implementatie onder de knie hebt, kunt u door te blijven verbeteren alleen maar meer tijd en middelen vrijmaken.
