WordPress-fokuserad kontinuerlig integration med CircleCI
Att skriva om kontinuerlig integration eller kontinuerliga distributioner verkar lite lustigt för mig med tanke på att jag har gjort det här förut och med tanke på att jag vet att många utvecklare redan använder detta som en del av sin vardag.
Men jag vet också att det finns många hobbyister, nybörjare och de som precis har börjat som letar efter sätt att se till att de sätter upp solida metoder för sitt arbete.
För vad det är värt, det var inte förrän jag började arbeta med några fler personer som vi började införliva en bredare uppsättning verktyg i vår implementeringsprocess.
Och det är syftet med detta inlägg.
Det är:
- introducera hela idén bakom WordPress-fokuserad kontinuerlig integration,
- introducerar CircleCI ,
- redo att prata mer om det.
Med det sagt, här är genomgången av allt ovanstående.
WordPress-fokuserad kontinuerlig integration
För det första, vad är egentligen den stora idén bakom kontinuerlig integration? Så den allmänna definitionen av kontinuerlig integration är :
Inom mjukvaruteknik är kontinuerlig integration (CI) metoden att slå samman alla utvecklare arbetskopior till en delad huvudlinje flera gånger om dagen.
Beroende på vilket källkontrollsystem du väljer kommer vad som anses vara din "huvudlinje" att variera. Om du använder GitHub kommer det sannolikt att vara din huvudgren (vilket är anledningen till att vi alltid bör arbeta i separata grenar, ha kodgranskning, och ställ in pull-förfrågningar).
Ta sedan det som finns i mastern och få det distribuerat till din mellanlagringsserver eller din produktionsserver.
Och även om det finns många verktyg för det, har mitt team och jag använt CircleCI för några projekt och jag är definitivt ett fan (pluss att de precis släppt den andra versionen av sitt arbete).
1 Vad är CircleCI?
CircleCI stiftar sig själv enkelt som:
Skapa anpassade miljöer, tillämpa arbetsflöden för kontroll över din byggpipeline, njut av flexibel resursallokering och mer.
som jag har blandade känslor för. Jag menar, allt är sant och det tillåter oss att ha anpassning över ett antal olika aspekter av våra implementeringar, men när det gäller att vara mindre skrämmande för dem som precis har börjat, jag vet inte.
Oavsett vilket har jag funnit att det kan vara så enkelt eller så komplext som ditt projekt behöver. Och eftersom det här handlar mer om att dela med mig av orsakerna till det, tänker jag inte gå in på allt det erbjuder.
Åtminstone inte i detta inlägg.
2 Hur använder vi det?
Förutsatt att du redan har ett GitHub-projekt konfigurerat, är det väldigt enkelt att ansluta CircleCi till ditt projekt.
När du registrerar dig kan du ansluta till GitHub, Bitbucket eller Google (även om jag är ett fan av att börja antingen med GitHub eller Bitbucket med tanke på att de har lagringsplatserna för kod som åtminstone många av oss i WordPress oftast använder) .
Därifrån måste du konfigurera en webhook till CircleCI. Detta kommer i huvudsak att få CircleCI att köra igenom de olika verktyg som du har konfigurerat och för att bygga ditt projekt. Jag ska prata mer om detta om en stund.
- Om bygget lyckas får du ett sådant meddelande och du kan begära en kodgranskning eller slå samman grenen till master.
- Om bygget misslyckas, kommer (och bör) det blockera möjligheten att slå samman grenen tills det finns ett framgångsrikt bygge.
Med det sagt, vad kan verktygen inkludera som är en del av en byggprocess för ett WordPress-projekt? Med tanke på att mycket av ett WordPress-projekt vanligtvis inkluderar PHP och JavaScript, kan du använda några av dessa:
- GrumPHP
- PHP CodeSniffer
- PHPMD
- ESLint
- Och mycket mer.
Om du har konfigurerat GrumPHP korrekt kommer den att titta på varje commit som går in i ditt arkiv (även när det är en lokal commit – det vill säga innan du trycker uppströms till GitHub).
Därför bör du veta om det finns ett problem med din kod innan du ens driver den uppströms. När de lokala kontrollerna har slutförts är du redo att skicka den till ditt förråd. CircleCI kommer sedan att utföra samma operationer baserat på din konfiguration i den miljö du har konfigurerat.
Om allt går bra så går det över och du kan som sagt slå ihop det. Annars måste du åtgärda de fel som rapporteras, återuppta och pusha. Vanligtvis, om den klarar en lokal commit, kommer den att passera en push. Men det är inte alltid fallet så anta inte så mycket.
Det kommer mera
Uppenbarligen är detta bara att skrapa på ytan av vad kontinuerlig integration kan göra. Ärligt talat, jag vet inte ens om jag skulle säga det – istället handlar det mer om att introducera idén om kontinuerlig integration och de fördelar det ger, särskilt när man arbetar med ett team.
Även om jag har provat en mängd olika verktyg, måste jag säga att jag har varit mest nöjd med vad CircleCI erbjuder. En av de saker som är bäst av allt är att om du väljer att bygga på en Linux-box så är den gratis att använda. Och det fungerar bra för ett litet team som vill hålla sig smalt.
Hur som helst, det finns mer att ta upp angående detta så jag ser fram emot att göra det i framtida inlägg.