Silverstripe CMS:n päivittäminen ja varmuuskopiointi

Silverstripe-sivuston ylläpito jatkuu ensimmäisen julkaisun jälkeen. Ohjelmistoon tulee korjauksia, moduulit kehittyvät ja palvelinympäristön vaatimukset muuttuvat. Samalla sivustolle kertyy sisältöä, jonka menettäminen voisi tarkoittaa huomattavaa lisätyötä.

Päivittäminen ja varmuuskopiointi kannattaa suunnitella yhdessä. Päivityksellä pidetään ohjelmisto ajan tasalla, kun taas palautettavalla varmuuskopiolla varaudutaan epäonnistumisiin. Kumpikaan ei yksin korvaa toista.

Silverstripessä päivitykset tehdään tavallisesti Composerin ja projektin oman julkaisuprosessin avulla. Työ vaatii enemmän teknistä ymmärrystä kuin sisällön muokkaaminen hallintapaneelissa. Tässä oppaassa käydään läpi turvallisen ylläpitotyön vaiheet ja tärkeimmät tarkistukset.

Selvitä ensin sivuston nykyinen tilanne

Ennen päivitystä tarvitset tiedon siitä, mitä sivustolla on käytössä. Pelkkä Silverstripen pääversion tunteminen ei riitä, sillä kokonaisuuteen kuuluu myös moduuleja, omaa koodia ja palvelinympäristö.

Kirjaa ainakin seuraavat tiedot:

• Silverstripen ja keskeisten moduulien versiot.
• Käytettävä PHP-versio.
• Tietokannan tyyppi ja versio.
• Sivuston omat integraatiot.
• Nykyinen julkaisutapa.
• Varmuuskopioiden sijainti ja palautusmenettely.

Projektin juurihakemistossa asennettuja paketteja voi tarkastella komennolla:

composer show

Saatavilla olevia uudempia versioita voi selvittää komennolla:

composer outdated

Jälkimmäinen ei päivitä sivustoa. Se auttaa tunnistamaan tarkasteltavat riippuvuudet. Composerin komentojen ohje.

Erota tavallinen päivitys suuresta versiovaihdosta

Pieni korjauspäivitys ja siirtyminen seuraavaan pääversioon ovat erilaisia töitä. Korjausjulkaisu voi sisältää rajattuja muutoksia, kun taas pääversiopäivitys voi edellyttää oman koodin muuttamista ja moduulien vaihtamista.

Lue tavoiteversion julkaisutiedot ja päivitysohje ennen riippuvuuksien muuttamista. Selvitä erityisesti poistuneet toiminnot, uudet vaatimukset ja mahdolliset tietokantaan kohdistuvat toimenpiteet.

Silverstripen virallinen päivitysopas ohjaa seuraamaan CMS-julkaisuja ja niiden edellyttämiä muutoksia. Silverstripen päivitysohje.

Älä oleta, että vanha sivusto voidaan nostaa usean pääversion yli yhdellä komennolla. Suunnittele siirtymä lähtöversion ja käytettyjen lisäosien perusteella.

Myös pienempi päivitys täytyy testata, jos se vaikuttaa sivuston keskeiseen toimintoon.

Mitä varmuuskopioon kuuluu?

Toimiva varmuuskopio kattaa koko palautettavan kokonaisuuden. Pelkkä projektikansion kopio ei sisällä tietokantaan tallennettuja sivutekstejä tai käyttäjätietoja.

Varmuuskopioitavia osia ovat yleensä:

• Tietokanta sisältöineen.
• Käyttäjien lataamat kuvat ja asiakirjat.
• Projektin oma ohjelmakoodi.
• Teemat ja rakennetut selainresurssit.
• composer.json ja composer.lock.
• Tarvittavat ympäristö- ja palvelinasetukset.

Silverstripen tiedostotallennus voi käyttää paikallista levyä tai erillistä tallennusratkaisua. Siksi todellinen aineiston sijainti pitää selvittää projektista. Silverstripen tiedostotallennuksen dokumentaatio.

Huomioi myös suojatut tiedostot. Niitä voidaan säilyttää erillisessä hakemistossa julkisen aineiston ulkopuolella. Tällainen hakemisto täytyy sisällyttää varmuuskopiointiin. Silverstripen palvelinvaatimukset.

Ota keskenään yhteensopivat kopiot

Tietokannan ja tiedostojen pitäisi vastata samaa tilannetta. Jos tietokanta kopioidaan aamulla ja kuvat illalla, niiden väliin voi syntyä eroja.

Esimerkiksi päivän aikana poistettu kuva saattaa edelleen esiintyä aamun tietokannassa, vaikka sitä ei enää löydy myöhemmästä tiedostokopiosta.

Sovi ennen päivitystä tarvittaessa lyhyt sisällönmuokkaustauko. Sivustolla voi olla myös lomakkeita, tilauksia tai taustatehtäviä, jotka kirjoittavat tietoja ilman ylläpitäjän toimintaa.

Valitse varmuuskopiointimenetelmä palvelinympäristön mukaan. Hosting-palvelun työkalu, tietokannan vientitoiminto tai ylläpidon automatisoitu ratkaisu voivat kaikki olla käyttökelpoisia, kun niiden sisältö ja toimintatapa tunnetaan.

Tarkista työn valmistuminen. Ajastettu tehtävä ei takaa onnistunutta kopiota, jos levytila loppuu tai tietokantayhteys katkeaa.

Säilytä kopiot erillään sivustosta

Varmuuskopio samassa palvelimessa auttaa joissakin tilanteissa, mutta ei suojaa palvelimen menetykseltä. Säilytä vähintään yksi kopio erillisessä, asianmukaisesti suojatussa paikassa.

Älä sijoita tietokantavientiä tai varmuuskopiopakettia julkisesti ladattavaan verkkohakemistoon. Kopio voi sisältää käyttäjätietoja, lomakevastauksia ja muita luottamuksellisia aineistoja.

Myös ympäristöasetukset voivat sisältää salasanoja ja rajapinta-avaimia. Silverstripen .env-tiedosto on tarkoitettu ympäristökohtaisten asetusten tallentamiseen, joten sen käsittely tarvitsee erityistä huolellisuutta. Silverstripen ympäristöasetukset.

Määritä säilytysajat sisällön muuttumisen perusteella. Päivittäin päivittyvä palvelu tarvitsee erilaisen varmistusrytmin kuin harvoin muuttuva esittelysivusto.

Nimeä kopiot niin, että ajankohta ja sivusto tunnistuvat helposti.

Kokeile palauttamista testiympäristöön

Varmuuskopion hyöty selviää palautuksessa. Pelkkä paketin olemassaolo tai onnistunut lataaminen ei osoita, että sivusto saadaan sillä toimimaan.

Palauta kopio erilliseen testiympäristöön ja tarkista:

• Tietokannan tuonti onnistuu.
• Sivut ja kuvat löytyvät.
• Hallintaan voi kirjautua.
• Oikeat ohjelmistoversiot ovat käytettävissä.
• Ympäristöasetukset vastaavat testiympäristöä.

Estä testikopiota lähettämästä oikeita asiakasviestejä tai käynnistämästä tuotannon integraatioita. Käytä tarvittaessa testitunnuksia ja rajaa ympäristön pääsy.

Kirjaa palautuksen vaiheet ja siihen kulunut aika. Näin tiedät, mitä ongelmatilanteessa tarvitaan.

Varmista myös, että palautusohje ja tallennuspaikan tunnukset ovat saatavilla silloinkin, kun varsinainen verkkopalvelin ei toimi.

Päivitä riippuvuudet ensin kehitysympäristössä

Composerin update– ja install-komennot palvelevat eri tarkoituksia.

composer update ratkaisee riippuvuuksien versiot projektin sallimien rajojen mukaan ja päivittää lukitustiedoston. composer install käyttää olemassa olevan composer.lock-tiedoston tarkkoja versioita. Composerin peruskäyttö.

Kehitys- tai testiympäristössä laajan päivityksen vaikutuksia voi ensin tarkastella:

composer update --dry-run

Tämä ei todista sivuston toimivuutta. Se näyttää suunnitellun riippuvuuksien muutoksen asentamatta sitä.

Varsinainen päivitys tehdään valitun päivityssuunnitelman mukaan. Kaikkien riippuvuuksien päivittäminen kerralla ei ole välttämätöntä, jos tarkoituksena on korjata vain rajattu kokonaisuus.

Älä poista yhteensopivuusrajoja tai ohita PHP-vaatimuksia saadaksesi komennon väkisin onnistumaan. Selvitä ristiriidan aiheuttava paketti.

Päivitä tarvittavat rakenteet ja testaa

Ohjelmistopakettien vaihtaminen voi edellyttää tietokantarakenteen päivittämistä ja välimuistin tyhjentämistä.

Silverstripe 6 -projektissa käytettävä komento voi olla:

vendor/bin/sake db:build --flush

Suorita se oikeassa projektissa ja varmista tietokantayhteys etukäteen. Komento voi muuttaa tietokantaa, joten se kuuluu varmistettuun päivitysprosessiin. Vanhempien versioiden komennot voivat poiketa tästä. Silverstripen Sake-ohje.

Noudata lisäksi moduulien mahdollisia erillisiä siirto-ohjeita. Yksi yleiskomento ei välttämättä kata kaikkea.

Testaa tämän jälkeen hallinta, sivujen julkaiseminen, kuvien lataaminen, lomakkeet ja keskeiset integraatiot. Tarkista myös rajatut sisällöt tavallisella käyttäjällä sekä uloskirjautuneena.

Suorita projektin automaattiset testit, jos niitä on käytössä.

Siirrä tuotantoon sama testattu kokonaisuus

Kun päivitys on tarkistettu, tallenna koodimuutokset ja composer.lock versionhallintaan. Tuotantoon pitää viedä sama kokonaisuus, jota testattiin.

Silverstripen ohjeessa tuotannon riippuvuudet asennetaan lukitustiedostosta esimerkiksi näin:

composer install --no-dev -o

Komento jättää kehitysriippuvuudet asentamatta ja optimoi automaattista luokkien lataamista. Vaihtoehtoisesti riippuvuudet voidaan sisällyttää etukäteen rakennettuun julkaisupakettiin. Silverstripen Composer-julkaisuohje.

Älä suorita tuotannossa uutta vapaata riippuvuuksien päivitystä testatun lukitustiedoston sijaan.

Ota juuri ennen käyttöönottoa tuore palautuskelpoinen varmuuskopio. Siirrä koodi ja suorita tarvittavat rakennus- sekä tietokantavaiheet projektin sovitussa järjestyksessä.

Varaudu palautukseen ennen ongelmaa

Päätä etukäteen, milloin päivitys perutaan. Esimerkiksi toimimaton kirjautuminen tai keskeisen lomakkeen rikkoutuminen voi estää käyttöönoton jatkamisen.

Pelkkä vanhan koodin palauttaminen ei välttämättä riitä, jos tietokantaa on jo muutettu. Palautettava koodi, riippuvuudet, tietokanta ja tiedostot on sovitettava yhteen.

Huomioi päivityksen jälkeen syntyneet tiedot. Vanhan tietokantakopion palauttaminen voi hävittää uusia lomakevastauksia tai sisältömuutoksia.

Älä kopioi testitietokantaa tuotannon päälle tavallisena julkaisutoimena. Testiympäristön tehtävä on varmistaa päivitys, ei korvata tuotannon ajantasaista sisältöä.

Hyvä palautussuunnitelma kertoo vastuuhenkilön, tarvittavat kopiot, toimenpiteiden järjestyksen ja tarkistukset ennen sivuston avaamista.

Tee ylläpidosta säännöllinen käytäntö

Päivityksen jälkeen tarkista sivusto julkisesta osoitteesta ja seuraa virhelokeja sekä tärkeiden toimintojen onnistumista.

Kirjaa muistiin päivityspäivä, muuttuneet versiot ja mahdolliset erityistoimet. Näistä tiedoista on hyötyä seuraavalla ylläpitokerralla.

Sovi erikseen vastuu:

• Päivitystiedotteiden seuraamisesta.
• Varmuuskopioiden onnistumisen valvonnasta.
• Palautusharjoituksista.
• Moduulien yhteensopivuuden tarkistamisesta.
• Ongelmien käsittelystä.

Aloittelijan kannattaa tehdä ensimmäinen päivitys kokeneen ylläpitäjän kanssa. Kun ympäristö, komennot ja palautusmenettely on dokumentoitu, seuraavat ylläpitokerrat ovat helpompia suunnitella ja toteuttaa.