Julkaisuiden jälkipuintia

Jälkipuintia asiasta...

Michael Babker - Production Leadership Team valottaa hieman asiota mitä tapahtui, mistä syystä ja mitä opimme tästä...

Plussaa mielestäni on yleensäkin, että avoimesti kerrotaan asioita(Michael Babker "Don't shoot the messenger ")
Lue jälkipuinti täältä: developer.joomla.org/news/597-release-postmortem.html

Terve pitkästä aikaa, JiiKoon pyynnöstä livautan tämän käännöksen osaksi ketjua:



Julkaisun jälkiselvittelyä

Kirjoittanut Michael Babker, julkaista alunperin 1.10.2014, kääntänyt Kharadus

Vaikka pyrimmekin olemaan niin tehokkaita, kuin vain mahdollista, tulee vastaan tilanteita, joissa asiat eivät menekään nappiin, ja käyttäjillemme, jotka testaavat ja auttavat viimeistelemään julkaisujamme, aiheutuu stressiä ja päänsärkyä. Kuluva viikko on ollut hyvä esimerkki hieman rankemmasta ajasta julkaisullemme, ja vaikka mikään yksittäinen ryhmä tai henkilö ei olekaan vastuussa viimeisimpien julkaisujen aiheuttamista ongelmista, on se silti hyvin selkeä näyte alueista, joissa tiimiemme ja työskentelytapojemme toimintaa voisi parantaa.

2.5.26/3.2.6/3.3.5 Päivitysbugi

Eilen julkaistuissa 2.5.26, 3.26 ja 3.5.5 –julkaisuissa ilmeni bugi, joka esti käyttäjiä päivittämästä sivustoaan Joomlan päivityskomponentin kautta. Koodi, joka liittyi tähän päivitysjärjestelmään, oli päivitetty vastauksena turvallisuusongelmaan, joka oli vasta ilmoitettu viimeviikon julkaisujen jälkeen. Koska tämä koodi pohjautui Akeeba Backupin Admin toolseihin, ja sitä käytetään yhtälailla niin Joomlassa, kuin Akeeban tuotteissakin, tiimit päätyivät yhteiseen koordinoituun julkaisuun tämän päivitetyn koodin kohdalla. Pian eilisen julkaisun jälkeen Akeeba-tiimi otti meihin yhteyttä, varoittaen mahdollisesta päivitysongelmasta, jonka korjaustiedosto saattoi aiheuttaa, joka kattavan testaamisen jälkeen paljastui molempien tiimien tuotteita koskevaksi.

Meille tarjottiin korjaustiedostoa seuraavan julkaisuun lisättäväksi varsin nopeasti, ja minä, tuotantotiimin johtajan asemassa päätin, että julkistamme sen mahdollisimman pian. Seuraavaa julkaisua valmistellessamme jouduimme keskittymään erityisen tarkasti hyvin kattavan dokumentaation tarjoamiseen kaikille vaikutuksesta kärsiville käyttäjille, koska päivityspolku ei ollutkaan tyypillinen yhden painalluksen päivitys. Päätimme myös lisätä päivityskomponenttiin eräänlaisen takaoven, jolla itse päivityskomponentti pystyttäisiin helposti päivittämään vastaavan tilanteen sattuessa uudestaan.

Varmistaaksemme, että tämä on kaikille selvä: tämä bugi itsessään ei vaikuttanut mitenkään Joomla-sivustojen jokapäiväiseen toimintaan, ainoa osa-alue, joka kärsi häiriöistä oli sivuston päivittäminen ja päivityskomponentti, etenkin se osa koodista, joka varsinaisen päivityksen ajaa. Lisäosien hallinnan kautta käyttäjä voi suorittaa päivitykset edelleen vaihtoehtoisesti, aivan kuten Joomlissa 1.6 ja 1.7 aikanaan.


Taantumia 3.3-julkaisuissa

Toinen ongelma, joka on ilmennyt lähiaikoina 3.3-julkaisuissamme, on useiden taantumien livahtaminen koodiin, ja vaikka nämä ovatkin suhteellisen pieniä suurimmassa osassa tapauksia, aiheuttivat ne silti keskeytyksiä sivustojen normaalissa toiminnassa.

Kaksi esimerkkiä tuoreista taantumista voi löytää sähköpostin verhoavasta liitännäisestä, sekä komponenttien sivunumeroinnista. Sähköpostin verhoavan liitännäisen tapauksessa pieni muutos oli tehty koodiin, joka renderoi verhotut sähköpostiosoitteet <div>-elementin sisällä, joka virheellisesti muokkasi sivustojen ulossaantia, näkyen jopa joomla.org-sivustoilla. Komponenttien sivunumeroituksessa virhe ilmaantui, kun muutos tietokannan kyselylogiikassa pyrki mahdollistamaan valittua APIa tarkemmin, mutta muutosta ei muokattu JModelListillä yhteensopivaksi sen tavoissa laskea sivunumerointia. Vaikka tämä bugi olisikin ollut havaittavissa testaamalla tilanne ympäristössä, jossa on riittävästi sisältöä, testaavat meidän Joomlan Bugitiimin aktiiviset jäsenet harvemmin tuotantotason sivustoja, keskittyen lähinnä ympäristöihin, joissa on lähinnä vain kaikkein kriittisimmät osiot asennettuina, koostuen vain vähäisestä sisällöstä tai rajallisesti määrää lisäosia.

Julkaisun ajoitus

Tyypillinen julkaisuaikataulumme pyrkii tuottamaan yleistä ylläpitoa julkaisuille kuudesta kahdeksaan viikon aikataululla. Valitettavasti tämä ei ole aina meidän päätettävissämme, ja voi vaihdella suurestikin useasta eri syystä, yksi isoimmista näistä turvallisuuteen liittyvät asiat.

Kuten jo mainitsemme ylempänä turvallisuusheikkoudesta, ei siitä saatu tietoa Joomlan henkilökunnalle, kuin vasta viimeviikkoisen julkaisun ilmestymisen jälkeen. Jos tiedote olisi tullut päivän tai kaksi aiemmin, oli noita julkaisuja todennäköisesti viivästetty ongelman korjaamisen ajaksi. Turvallisuusratkaisut pyrimme toimittamaan yhteisömme jäsenille rivakkaa tahtia, ja pyrimme välttämään ongelmien aiheuttamista toimittamalla useita pienempiä julkaisuja putkena.

Otimme opiksemme

On paljonkin opittavaa tavasta, jolla julkaisut tapahtuivat ja ongelmista, jotka on pantu merkille tulevaisuuteen jatkaessamme. Tuotannonjohtoryhmä (Production Leadership Team) etsii tapoja parantaakseen julkaisukäytäntöjämme ja tuotteiden tutkimistasoamme, niin käyttäjien kokeiden osalta, kuin automatisoitujen testienkin
kannalta. On kuitenkin tärkeätä huomata, ettemme voi luvata saati tarjota täydellistä järjestelmää. Virheitä sattuu, on vain tärkeää minimoida niiden vaikutus ja oppia niistä.