Project Guardrails: Writing to Production
I de senaste artiklarna har jag pratat om ett par saker (sparade för att faktiskt skriva till produktion) som hjälper till att driva ett framgångsrikt projekt:
- Farorna med " design av kommitté ",
- Överväganden för att tillhandahålla en miljö.
Det sista jag vill ta upp det lärande jag har upplevt hittills handlar om att behålla de ökända nycklarna till skrivandets rike till produktion och varför det är viktigt.
Skriva till produktion
Tanken på att skriva till produktion kan tyckas vara det mest dogmatiska skyddsräcket av de nämnda eftersom det vanligtvis är okej för dem som bygger lösningen och de vet hur det fungerar.
De andra intressenterna gör det sannolikt inte (men om de gör det och utvecklingsteamet är okej med att de andra använder versionskontroll för att hantera detta, så kör på det).
Vem har tillstånd att administrera det här egentligen?
Kom dock ihåg, som nämnts tidigare i den här serien, sättet på vilket vi distribuerar våra projekt har förändrats nu så att vi ofta har kontinuerlig driftsättning och kontinuerlig integration.
Och ofta är dessa tjänster anslutna till ett källkodsförråd, såsom GitHub, och ett meddelandesystem (som i sin tur kan vara anslutet till Slack vilket jag tycker är användbart).
Så att folk i teamet är medvetna om vad som har distribuerats och när och de vet hur de ska hämta koden (som är från förvaret, inte från att ladda ner den via S/FTP) om det behövs.
När en snabbkorrigering behövs bör det fortfarande finnas en procedur på plats. Kanske har någon jour, och det finns en process där förgrening, sammanslagning, taggning och semantisk versionering används.
Oavsett så handlar det inte så mycket om hur processen fungerar; det är att det är på plats och att det följs.
Naturligtvis är dessa saker inte inrättade för att göra utvecklingen mer komplicerad (även om jag förstår hur det kan verka så). Det är tvärtom. Det är av en mängd olika anledningar:
- för att hålla kontinuerlig driftsättning, du vet, kontinuerlig,
- att ha integrerade tester,
- att kontinuerligt mäta kodningsstandarder eller kodkvalitet,
- för att förhindra cowboykodning,
- och mer.
Det handlar inte så mycket om att hålla andra människor utanför, men om det är utvecklarnas ansvar att pusha kod, borde då verkligen någon annan ha skrivåtkomst till servern?
Och det är slutsatsen: Om du arbetar i ett team där de processer du har på plats helt kan undergräva det arbete du gör, vad är då syftet med processen?
För när som helst kan någon annan komma och detta bortse från allt du har gjort. Du är då åtminstone:
- fastnat med att behöva dra sina ändringar troligen via S/FTP,
- jämför det med ett diff-verktyg mot en gren som någon arbetar på,
- implementera ändringarna (låt oss ta reda på varför de gjordes),
- och sedan återgå till arbetet med kraven.
Det låter hektiskt när man uttrycker det så, men det är precis vad som händer.
Takeaway
Så vad är hela syftet med de senaste inläggen? Om jag måste sammanfatta det så kortfattat som möjligt är det:
När det kommer till ett projekt, känna till ditt ansvar och gå inte utanför dem. Annars riskerar du att spåra ur hela grejen.
Detta gäller utvecklare, designers, uppdragsgivare, marknadsförare, projektledare etc. Hur rollerna är utsedda, vet inte så mycket spelar roll (jag menar, det brukar vara tydligt vem som ska vara vem i rollerna ovan) men jag menar m.t.t. vem den faktiska poängpersonen är – projektägaren – för hela projektet.
Var inte så här.
Och beroende på hur allt ovanstående går, kan projektet vara en relativt enkel uppsättning av dagligt arbete.
Så mycket som möjligt, vill vi inte njuta av det vi gör