Què torbes a corregir un error de producció?

Escrit per Aaloy a 18 de November , 2007 a les 4:34 p.m.

Trobar un error al teu codi és un emprenyo. Poder començar la depuració en 30 segons, trobar l'error 2 minuts, pujar-ho al subversion i actualitzar la versió de producció de manera que als 5 minuts d'haver detectat l'error estigui corregit no té preu.

Això és el gran avantatge dels llenguatges d'script, que el temps que passa des de que trobes un error a poder-ho corregir és molt curt (llevat d'excepcions amb errors difícils de trobar i depurar, clar). Curt perquè normalment posar en marxa l'entorn de desenvolupament no duu més que uns pocs segons i ja pots començar a depurar.

Si tot està ben organitzat el codi estarà a un repositori subvesion i l'entorn de producció no serà sinó un client de subversion, de manera que fer una actualització una vegada trobat un error que no afecti a la base de dades, és bàsicament

• svn ci
• ssh al servidor
• svn update

I en alguns casos recarregar l'Apache. Encara desenvolupament i sistemes siguin equips separats, davant un error crític el temps de resposta pot ser tan curt com 5 minuts.

L'experiència amb Java és que ja directament és necessiten els 5 minuts sols per posar en marxa l'entorn, 5 o 10 minuts més per depurar i si hi ha sort i sols era un error de jsp 2 mintus més actualizar i forçar la compilació del jsp per a que el proper usuari no vegi en enlentiment en la pàgina. Normalment més del doble per a corregir el mateix tipus d'error.

Si la correcció de l'error implica canviar codi que no sigui jsp o html les diferències són encara més grans i sovint pot implicar tenir que reiniciar el servidor, la qual cosa ens obligarà a tenir sempre dos servidors balancejats si no volem tenir als usuaris aturats durant 5 minuts. L'Apache es recarrega en segons, i tot i que sempre és bo tenir-ho tot duplicat i balancejat, la necessitat no es tan forta com en el cas anterior.

Personalment m'agrada molt Java i les llibreries que s'han desenvolupat en aquest llenguatge, però si el nostre negoci depèn del ràpid que puguem actualitzar la nostra aplicació web hi ha entorns i llenguatges amb més avantatges que Java o .Net.

4 comentaris, 0 trackbacks (URL) , Tags: Python Java Gestió de projectes

Escriure un joc de proves per el cas que falla.

Executar-lo, arrancant el context d'spring (no tot el servidor), per veure que hem detectat l'errada. (pot implicar crear o no el SessionFactory d'hibernate, segons la prova)

... 3 minuts

fer commit del nou test.

Solucionar-ho.

... 3 minuts

Passar el joc de proves complet per provar que funciona i no hem introduït bugs de regressió.

... 4 minuts

fer commit.

contruir l'aplicació i passar-ho a produccio ... 2 minuts

Es més temps ... però no tant i hi ha altres avantatges

salutacions i enhorabona per el bloc! només és per fer un poc de polèmica ;-)

Um, 12 minutets molt optimistes :)
Hi ha molt avantatges de fer les coses en Java, de fet defens el poder anar a un model híbrid on la capa de presentació estigui feta en un llenguatge d'script com el Python que consumeixi serveis web (XML,SOAP, Json) desenvolupats en Java.
L'experiència ens diu que els temps de desenvolupament és menor i que l'escalabilitat, tant de l'entorn com del propi desenvolupament és força millor.
La cosa estar en que no tenim que casar-nos sols amb una sola tecnologia, quan feim aplicacions web podem optar per models híbrids i aprofitar el millor dels dos mons.
Fes una ullada a http://trespams.com/2007/09/15/cap-a-una-nova-arquitectura-de-desenvolupament/
a veure què hi trobes.

Molt interessant la idea que proposes.

Efectivament, la idea d'empaquetar l'aplicació, i el procés de desplegament i pre-compilació no casa gaire bé amb el requeriment de resposta ràpida a errades.

El que hem xoca una mica és l'ús de web services dins la mateixa aplicació, i no només per la inter-operabilitat entre distints sistemes.

Degut al sistema de producció que ens ve imposat, estic limitat a la aproximació j2ee tradicional (sí, el 2 hi ha de ser :-( ) . Per donar més pistes (y hasta aqui puedo leer), el pas a producció no és de 4 minuts sinó de una o dues setmanes (doblament :-( ).

Per tant, fora haver-ho provat, si tingues la llibertat afrontaria el problema que adreça la teva arquitectura de la següent forma:

- capa de lògica amb el nostre estimat Java. Probablement Spring i Hibernate
- l'exportació d'aquests serveis ho feria amb Servlets i JSP.
- els web services els reservaria en cas d'haver de interaccionar amb serveis externs.
- la capa de presentació estaria amb HTML, css i javascript però fora de l'ear, servit directament per l'apache.

La part important és el paper jugat per els JSP i servlets. Només fa permetre l'accés http als serveis, això és, construir XMLs amb les dades, tractar els paràmetres i accedir a les classes. Aquestes parts del codi acumulen una part insignificant de les errades.

La part client, lògicament molt més complexe i per tant candidata a contenir errades, podria ser canviada directament al servidor, sense cap desplegament.

La separació de l'aplicació entre el servei i la presentació no és més que donar-li una volta més al tema de la separació de capes. Per una banda tens els serveis web, la fontaneria dels quals pot ser tan complexa com vulguis, i per una altra banda tens la part que consumeix aquests serveis, que pot ser molt lleugera.
A la capa de serveis Spring, Hibernate, EhCache, XFire damunt Tomcat(ts) i balancejadors Apache per escalar.
A la capa de presentació en el meu cas Django i ZSI per a comsumir els serveis corrent a Apache amb mod_python.
Això permet fer aplicacions molt més lleugeres i no tan acoplades a una sola tecnologia.
Per una altra banda, de retruc ja tens tot un conjunt de serveis que poden ser directament reaprofitables per altres aplicacions sense tenir que tirar de llibreries.
La contra? Una necessitat major de CPU donat que processar XML o SOAP no és barat, però tant la CPU com la memòria són cada dia més barates.