Utvecklingsmiljön i molnet

För ett tag sedan satte vi upp en hel utvecklingsmiljö i molnet (nästan) i ett projekt av medelstorlek. Erfarenheterna är goda!

I början av projektet startade vi med ett blankt blad eftersom den befintliga IT-miljön i organisationen inte på ett enkelt sätt stödde distribuerade team, vilket vårt projekt hade som krav.

Som fileserver för projektfiler körde vi helt enkelt Dropbox. Då behövde vi inte sätta upp en Windows fileserver på kontoret, behöva tänka på backup av den och framför allt inte problemet att släppa ut den genom brandväggen så de andra teamen som alltså inte fanns på samma kontor också på ett smidigt sätt kunde nå den. Vi slapp också VPN vilket jag hittils upplevt som ett hanteringsmässigt gissel och är okej bara om inga alternativ finns.

Som dokumentarkiv körde vi SharePoint. Ett av bolagen som var involverade hade redan en sån uppsatt så den gick att nå från internet via webbläsare. En egen SharePoint-installation kanske inte klassas som molntjänst, men den är iaf oberoende var man sitter. Ett snabbare och smidigare alternativ är faktiskt Google Documents om man kan tänka sig att gå ifrån sina Word-mallar. En sån lösning kräver inte att man har en SharePoint uppsatt. Min son har introducerat Google Documents i sina grupparbeten på gymnasiet och de stödjer att flera personer redigerar i samma dokument samtidigt – imponerande tycker jag. Jag är lite oklar över vilka bra och lättanvända alternativ till SharePoint som finns om man vill ha ett webbaserat filarkiv. De jag hittils sett har jag inte direkt stått och hurrat över beträffande deras usability.

Samma SharePoint-installation tillhandahöll också Wiki. Jag är nyfiken, finns det projekt som inte har en projektwiki för allehanda informella instruktioner, checklistor, beskrivningar av utvecklingsmiljö – dvs allt som man inte vill ha som formella Word-dokument? En lite trist sak med SharePoint är att alla måste använda Internet Explorer eftersom editorn blir i praktiken oanvändbar i andra webbläsare. I andra projekt har jag satt upp och kört Mediawiki, dvs samma som t.ex. Wikipedia använder. Wiki finns att hyra på många olika sajter.

En Wiki-sajt backar man upp med ett wget-kommando som rekursivt kopierar en sajt till en directorystruktur, på så vis kan man t.o.m. bära med sig en snapshot av Wikin på ett USB-minne om sajten skulle dö:

wget -E -p -r -l inf -k --http-user=... \
  --http-password=... https://foo.com/projectxwiki

Som versionshantering körde vi Git på http://www.codebasehq.com. När vi tog beslutet om huruvida vi skulle våga lägga vår kod där från ett backupperspektiv så var vi beredda på att om sajten lades ned eller om de helt enkelt schabblade bort hela vår databas så funkar Git så att alla datorer har hela versionshistoriken och så länge bara någon i projektet har sin dator kvar så kan vi ta databasen från den och flytta till en annan Git-server. Alltså brydde vi oss inte om att kontrollera hur duktiga codebase var eller vilka garantier de kunde ge. Så länge det funkar så är det bra, och så långt har vi kört kontinuerligt i ett halvår mot codebase, med bara små driftsavbrott när deras servrar inte varit nåbara. Jag är mycket nöjd med funktionerna som codebase tillhandahållit. Dock var det lite krångel med ssh som vanligt, både på Windows men även på Linuxdatorerna faktiskt.

Ärendehanteringen körde vi också via codebase. Vi kollade runt först på ett antal alternativ att hyra en Jira-instans. Det fanns gott om möjligheter där.

Det vi inte hade i molnet var testservrar och continuous build (Jenkins/Hudson) då vi ville ha stor kontroll över klusteruppsättningar, databaser, nätverk m.m. Men egentligen, det kanske är tvärtom – att molnet kanske erbjuder både mer kräm, kontroll och variation även i detta avseende än egna servrar i testlabbet. De flesta vet nog hur jobbigt det kan vara och hur lång tid det kan ta att få loss pengar för investeringar av den här sorten i projekten.

Så här finns definitivt lite kvar att utforska. Ett argument emot att lägga ut Jenkins i molnet är att dessa maskiner alltid går varma – de skall ju liksom gå kontinuerligt – och det kan beroende på betalningsmodell bli dyrt.

Gränslösheten och smidigheten gav en hel del i produktivitet. Exempel från en vanlig tisdag: Vid dagens slut committade jag de sista ändringarna och gick hem. En liten stund senare på tunnelbanan sade det pling i mobilen när en av våra Jenkins-instanser meddelade mig via mail att den committen jag gjorde precis innan jag gick hem gjorde att en integrationstest small. Jag vek upp netbooken, hämtade den senaste versionen, hittade felet, provkörde testen, committade och pushade och några minuter senare plingar det till i mobilen igen från Jenkins “Build back to normal”.

Om man skall leta nackdelar så skulle väl det kunna vara att man kan jobba jämt och varsomhelst med den här tekniken.

IT Consultant at CAG Edge. Cloud and Continuous Delivery specialist, software developer and architect, Node.js, Java.

Publicerad i Cloud Computing, Java, Linux, Windows
One comment on “Utvecklingsmiljön i molnet
  1. Jimmy skriver:

    Stort tack för wget-tipset för att backa en sajt/wiki. Skall testas omgående. Jag har använt DokuWiki och senare MediaWiki som PIM under många år. Primärt så kör jag shell-scripts som backar databas- och webbservern men det här känns som en pragmatisk och snabb lösning som jag ska testa som komplement. Stort tack!

    Mvh, Jimmy

Kategorier

WP to LinkedIn Auto Publish Powered By : XYZScripts.com