Tagg arkiv: förbättringar


Kan man undvika förgreningsträsket?

När man utvecklar system så hamnar man ofta i dilemmat att man måste vidareutveckla och samtidigt underhålla koden i produktion. Det finns många olika alternativ man kan använda för att lösa detta. Jag förutsätter att man använder någon form av versionshanteringssystem för att ha en chans att klara av detta överhuvudtaget.

Ett populärt sätt är att använda grenar (branches) för att arbeta med koden i produktion och nyutveckling parallellt. I praktiken upptäcker man snabbt att detta medför ett antal problem att ta ställning till. Här är några exempel:

  • När ska man mergea ner koden till trunken? Ska man göra en ny gren när det är dags för produktionssättning? Eller ska man kanske bara göra nya grenar baserat på den senaste utvecklingsgrenen?
  • Ska man systemtesta applikationen i utvecklingsgrenen eller bara i produktionssättningsgrenen när man är klar med utvecklingen? Både och är förstås att föredra men om det inte finns resurser till detta?
  • Hur gör man om beställaren ångrar sig och vill ta bort vissa funktioner och samtidigt vill lägga till andra helt nya mitt under utvecklingen i grenen?
  • Vad gör man om det dyker upp akuta buggar i produktion?
  • Hur hanterar man beställarens krav på täta releaser när de inte riktigt passar ihop med tiden det tar att utveckla vissa delar av applikationen?
  • Hur hanterar man automatiska byggen när man använder flera grenar?
  • Vilken gren ska man utveckla i? Är det trunken eller någon annan obskyr gren som ingen längre har någon koll på?

Optimalt vore ju om man kunde hantera samtliga problem på bästa möjliga sätt för samtliga parter i projektet vilket ofta kan vara komplicerat.

Jag läste nyligen om ett sätt att komma en bit på vägen genom att använda förgrening genom abstraktion (branch by abstraction) tillsammans med omkopplingsbara egenskaper (feature toggles).

Förgrening genom abstraktion

Man kan abstrahera bort problemet genom att göra två implementationer, dels den gamla befintliga och dels den nya som ska ta över.  Dessa implementationer kan finnas parallellt och man ser till att gå över till den nya koden så snart denna är på plats, testad och klar. Därefter kan man ta bort den befintliga legacy koden och saken är klar. Det bästa är att de automatiska byggena alltid bygger och att man inte begränsar produktionssättningarna då koden alltid är i fungerande skick.

Omkopplingsbara egenskaper

Med omkopplingsbara egenskaper kan man enkelt konfigurera sin applikation vilka egenskaper denna ska ha. Detta gör att man kan slå av och gömma de funktioner som ännu inte är klara och därmed inte ska ut i nästa produktionssättning.

Genom att använda dessa tekniker kan man komma ganska långt och troligtvis slippa behovet av att skapa en massa nya grenar.

Jag rekommenderar att läsa de ursprungliga artiklarna för en djupare förståelse.

Lycka till!

Källor
http://continuousdelivery.com/2011/05/make-large-scale-changes-incrementally-with-branch-by-abstraction/
http://paulhammant.com/blog/branch_by_abstraction.html
http://martinfowler.com/bliki/FeatureToggle.html

Nu har Gingerbread 2.3.4 kommit!

I morse kom den uppdaterade Android versionen av Gingerbread till min Nexus One telefon via OTA. Den har nu uppdaterats till version 2.3.4 bygge GRJ22.

Den största nyheten är möjligheten till video chat via Google Talk men tyvärr finns bara en kamera på Nexusen så det går inte att se varandra samtidigt. Övriga nyheter är diverse buggfixar och ytterligare optimeringar för bl.a. batteritiden.

OTA står för over-the-air och innebär att uppdateringarna automatiskt skickas till telefonen.

Källor
http://www.google.com/support/forum/p/Google+Mobile/thread?tid=3812c1acf93b482f&hl=en

Powered by WordPress