No more redeploys ?
- ons 7 maj, 2008 kl 12:42
- 8 kommentarer
- Java
Patcha din java app i runtime (från jdk 1.4 och uppåt). Tyvärr ingen gratis programvara – men den verkar klara en hel del.
http://www.zeroturnaround.com/javarebel/features/
Känns som en klart användbar ”liten pryl”.
Visst, lite snyggt. Men ändå bara ännu en ”fullösning” för att slippa göra sin kod testbar i mindre enheter.
Vet inte om du talar av egen erfarenhet Stefan, men sitter man och irriterar sig på att det tar för lång tid att publicera en ändring på sin testserver är risken stor att koden är för hårt kopplad till servern…
Nej, arbeta bort beroenden och gör det väsentliga enhetstestbart istället. Då kanske det räcker att starta servern någon gång per dag, och det är ju inte riktigt lika kännbart!
Jag ser främst en möjlighet att patcha i produktion utan att behöva ta ner systemet. Istället för att uppgradera i produktion med omstart etc kan man med detta verktyg bara byta ut de klasser som berörs utan att ta ner systemet.
Funkar kanske inte överallt men förmodligen på de flesta ställen när det är mindre buggar som skall fixas snabbt.
Tomas,
Jag håller med dig om att det kan vara ett praktiskt användningsområde (om man inte har så stora krav på spårbarhet osv), men på sajten talas det nästan bara om hur mycket tid man kan tjäna på sparade omdeployer till IDE:ns testmiljö.
Jag håller helt med Martin.
Visst låter det som en kul pryl att leka med, men i professionella sammanhang är det ett fulhack. Nej, angrip det verkliga problemet i stället. Dålig design.
I ett utvecklings-scenario: Fokusera på skriva kod som är testbar med enhetstest.
I ett produktions-scenario: Om uptime är viktigt, satsa på ett dynamiskt modulbaserat system (läs OSGI).
Jag tror vi tänker på lite olika saker.
Jag håller med er båda till 100% MEN det är inte alltid man kan skriva om alla system alltid och absolut inte just när det visar sig en finnas en bugg.
Världen är inte perfekt och det finns massor av system därute skrivna av andra som inte gör lika fantastiska system som er.
Antag att ni hamnar i ett av dessa, ett stort system med massa buggig kod och där det är allvarligt om systemet går ner.
Är inte detta ett bra verktyg då?
Det behöver inte bli fulhack heller. Ändringen skall naturligtvis checkas in, testas mm som vanligt men istället för att bygga en ny war/ear och deploya om så uppdaterar man bara de ändrade filerna i runtime.
Eller så kan man uppdatera klasser i runtime/produktion med utökad loggning för att analysera ett fel som man kanske inte riktigt vet vad det beror på, kan absolut se användning av detta.
Jag köper de argumenten Tomas, men bara om vi pratar om hyfsat kortsiktiga lösningar för att underlätta för ett befintligt problembarn under tiden som man försöker att arbeta bort ”utmaningarna”!
Det är nog inte tänkt som en ersättare till modulär programmering eller enhetstester.
Med bra enhetstester kan mycket såklart fångas.
Om dom trycker på att den stora vinsten är sparad tid utan redeploys – så ser i varje fall jag andra fördelar med programvaran.
När man väl står där med ett fel kan det vara en fördel att kunna fixa det utan att ta ner hela systemet.
Sedan skulle man kunna diskutera interpreterande språk i allmänhet.
En fördel med dom är just run-time patchning. Stödet för detta ökar också från och med java 1.6
Sedan får man inte överskatta enhetstestning.
Ja, det är bättre med enhetstestning än utan, men det är inte alltid den mest kostnadseffektiva testningsmetoden, och en stor kategori fel hittar man inte.
Korta deploymentcykler är bättre än långa, och möjligheten att panikrätta är bättre än att inte ha möjligheten.