Manuaali: julkaisukohteet ja oma verkkotunnus

Käyttöönotto omalle palvelimellesi tarkoittaa, että annat agentille SSH-tyyppisen pääsyn koneeseen, josta maksat ja jolla saattaa jo olla muita asioita. Se on eri luottamustaso kuin julkaiseminen ilmaiseen alidomainiin, ja asetusprosessi heijastaa tätä — muutama kenttä, täytetään kerran, ja sen jälkeen jokainen build on yhden painikkeen takana. Tässä ovat kysymykset, joita ihmiset todella kysyvät ennen ja jälkeen kohteen määrittämisen.

Mitä tarvitsen kohteen luomiseen?

Viisi asiaa kohdassa Asetukset → Käyttöönotto:

1. Nimi, jonka tunnistat myöhemmin — "prod-vps", "asiakas-hostgator", mikä tahansa mikä selviää pudotusvalikosta kello 23
2. Isäntä ja portti
3. SFTP-tunnukset
4. Verkkojuuripolku

Ei API-tokeneita, ei asennettavaa CLI:tä palvelimelle, ei cron-työtä vahdittavaksi. Jos isäntäsi tarjoaa SFTP-pääsyn — mikä kattaa lähes kaikki jaetut palvelinpaketit, VPS:t ja hallitut WordPress-tilit — olet valmis noin kahdessa minuutissa.

Salasana vai avain?

Avain, jos isäntäsi tukee sitä. Salasanat toimivat hyvin ja tallennamme ne tiliisi rajattuina, mutta avain on yksi salaisuus vähemmän missään — ero "peruuta avain" ja "nollaa salasana kaikkialta, missä tuo sama salasana sattui olemaan käytössä" välillä, jos jotain menee myöhemmin pieleen. Monet halvat jaetun hostingin SFTP-asetukset tarjoavat vain salasanatodennuksen, ja se on ihan ok myös. Älä vain käytä sitä salasanaa muualla.

Miten löydän oikean verkkojuuripolun?

Tämä on kenttä, jossa ihmiset erehtyvät ensimmäisellä kerralla, koska väärä vastaus näyttää silti uskottavalta. Se ei ole kotihakemistosi, se ei ole /var/www — se on täsmälleen se kansio, josta verkkopalvelimesi on määritetty tarjoilemaan.

Jos et ole varma, pudota kertakäyttöinen test.txt kansioon, jonka uskot olevan oikea, millä tahansa SFTP-asiakkaalla, ja tarkista sitten, latautuuko se osoitteessa yoursite.com/test.txt. Jos teet tämän väärin, käyttöönotto raportoi silti onnistuneen — agentti kirjoittaa tiedostot tunnollisesti väärään kansioon, ja sinä jäät tuijottamaan live-sivustoa, joka ei ole muuttunut, ihmetellen miksi.

Voiko yksi kohde kattaa useamman kuin yhden verkkotunnuksen?

Kyllä, ja tämä osa säästää oikeasti aikaa, kun olet ohittanut ensimmäisen sivustosi. Kohde on yksi palvelin ja yksi tunnussarja — se ei ole sidottu yhteen verkkotunnukseen. Verkkotunnusten hallinnassa liität kunkin verkkotunnuksen kohteeseen omalla verkkojuuren ohituksellaan. Pyöritätkö kolmea sivustoa yhdellä VPS:llä Nginxin server-lohkoilla?

• site-a → /var/www/site-a
• site-b → /var/www/site-b
• site-c → /var/www/site-c

Yksi kohde, kolme liitosta. Et syötä SSH-salasanaa kolmesti, etkä ylläpidä kolmea lähes identtistä kohdetta, jotka ajautuvat eroon sinä päivänä, kun vaihdat avaimen ja unohdat yhden niistä. Klikkaa käyttöönotto millä tahansa kolmesta verkkotunnuksesta, ja se tietää jo, mikä palvelin ja mikä kansio — et koskaan valitse käyttöönoton yhteydessä.

Mitä agentti oikeasti tekee, kun se yhdistää?

Ensin se katselee ympärilleen — vain lukuoikeudella, mitään ei vielä kirjoiteta. Se tarkastus etsii:

• Tyhjää kansiota
• Saman buildin aiempaa versiota
• Vanhaa WordPress-asennusta
• "Pian avautuu" -paikanpitäjää, jonka isäntäsi laittoi sinne oletuksena

Se ratkaisee strategian. Tyhjä verkkojuuri saa suoraviivaisen latauksen. Verkkojuuri, jossa on jo jotain, käsitellään varovaisemmin, koska monissa oikeissa asetuksissa on sivuston rinnalla asioita, joiden ei pitäisi kadota:

• A .well-known -kansio SSL-vahvistusta varten
• An uploads -hakemisto, jota kukaan ei laittanut git:iin
• A wp-config.php jota kukaan ei halua koskea

Tehtävä tässä on lähempänä "selvitä mikä muuttui ja sovita se yhteen" kuin "pyyhi ja korvaa".

Sitten, ennen kuin yhtäkään tavua ylikirjoitetaan, nykyinen verkkojuuri kaapataan versioksi omalle isännällesi. Ei tietokantatietuetta, ei diffiä jonka laskemme ja toivomme olevan oikein — vaan oikea tilannekuva siitä, mitä siellä todella oli. Tämä on tärkeintä juuri ensimmäisessä käyttöönotossa mihin tahansa kohteeseen, koska se käyttöönotto laskeutuu aina jonkin päälle, vaikka se jokin olisi tyhjyys. Tyhjä kansio, tyhjä tilannekuva. Viisi vuotta vanha staattinen sivusto, jota kukaan ei muista rakentaneensa — säilytetään täsmälleen, ilmaiseksi, ennen kuin siihen kosketaan. Se ensimmäinen käyttöönotto on myös se, josta olet vähiten varma, joten se on se, jossa tällä on eniten merkitystä.

Lataako se lähdekoodini vai valmiin sivuston?

Julkaistu sivusto, aina. Staattisen sivuston kohdalla se tarkoittaa generoituja sivuja. Framework-buildissa — Next.js, Vite, mitä sivustotyyppi sitten vaatiikin — se on käännetty output, eli dist tai build -kansio, ei koskaan lähdekoodipuu. Uskon, että tämä on oikea ratkaisu, vaikka se tarkoittaa, ettet voi ottaa SSH-yhteyttä ja ajaa npm run dev sitä, mitä palvelimella on. Lähdekoodin lataaminen tarkoittaisi, että tuotannon webroot tarvitsisi Node-ajonaikaisen ympäristön ja build-työkalut vain HTML:n tarjoilemiseen — muuttaen jaetun hostingin palvelimen, jota ei koskaan ollut tarkoitettu ajamaan build-putkea, sellaiseksi, ja tehden jokaisesta julkaisusta "toivotaan, että palvelimella on tarpeeksi muistia saattaa loppuun npm install." Kun toimitat vain käännetyn outputin, webroot pysyy juuri sellaisena kuin staattinen tiedostopalvelin odottaa. Tylsää. Tylsyys on juuri se, mitä haluat kello kahdelta yöllä, kun jokin on rikki ja tuijotat kyseistä kansiota yrittäen selvittää, mitä oikeasti tarjoillaan.

Mistä tiedän, että käyttöönotto todella onnistui?

Latauksen jälkeen agentti käy live-URL:ssa ja tarkistaa, latautuuko se — ei 500-virhettä, ei tyhjää sivua. Kaikki mitä se löytää, sekä mahdolliset huomiot tarkastuksen aikana, joihin se haluaa sinun kantasi ("tässä webrootissa on wp-content -kansio, jonka jätin koskematta, vahvista että tämä on odotettua"), päätyy buildin keskusteluketjuun. Se on kaava koko tämän alustan läpi: ei hiljaista onnistumista, ei hiljaista epäonnistumista, joka päätyy tukipyyntönä. Agentti kertoo, mitä se näki ja mitä se päätti, samassa ketjussa, jossa pyysit buildia.

Mitä versiohistoria oikeastaan sisältää?

Jokainen käyttöönotto lisää version — ei vain ensimmäinen. Historia ei siis ole buildisi piirrettynä abstraktille aikajanalle; se on kirjaimellinen sekvenssi siitä, mitä kyseisestä verkkojuuresta on tarjottu, järjestyksessä, alkaen siitä mitä siellä oli ennen kuin ilmestyit. Versio yksi on aina se alustaa edeltävä tila, kaapattuna automaattisesti. Sinun ei tarvitse ajatella sitä.

Mitä palautus oikeastaan palauttaa?

Edellisen live-version, täsmälleen — ei vanhan buildin uudelleenajoa, ei approksimaatiota. Ne varsinaiset tiedostot, jotka palvelivat liikennettä ennen. Se on merkittävästi vahvempi tae kuin useimmat muualla käyttämäni "palautus"-ominaisuudet, jotka yleensä tarkoittavat "ota uudelleen käyttöön vanhasta commitista" ja hiljaisesti olettavat, että build-prosessisi on deterministinen eikä ympäristösi ole ajautunut. Tässä palautus on tunnetusti hyvän tilannekuvan palautus, minkä vuoksi siihen on turvallista turvautua paineen alla — sinun ei tarvitse pohtia, saattaako palautus käyttäytyä eri tavalla kuin se, mitä se palauttaa.

Ja hetki, jolloin oikeasti tarvitset sitä, ei ole koskaan rauhallinen; se on "uusi build rikkoi kassan ja liikenne on live juuri nyt".

Yksi klikkaus, edellinen versio palautettu, valmis. Perustelut sille, miksi tätä kohdellaan ensiluokkaisena ominaisuutena eikä jälkiajatuksena, löytyvät artikkelista Iterointia ilman pelkoa — kannattaa lukea kerran, ennen kuin sitä tarvitset. Sekä historia että palautuksen ohjaus löytyvät build-kortilta ja kohteen omasta historianäkymästä.

Varmuuskopioiko tämä myös tietokantani?

Ei, ja sanon sen mieluummin suoraan kuin annan kenenkään olettaa toisin. Isännällä oleva versiohistoria kattaa vain sen, mitä tämä käyttöönottoputki laittoi verkkojuureen. Jos sivustollasi on tietokanta, käyttäjien lataamia tiedostoja tai mitä tahansa muuta, mikä muuttuu käyttöönottojen ulkopuolella, se on täysin erillinen asia — palautus ei koske sitä eikä sitä pidä sekoittaa sellaiseen varmuuskopiointistrategiaan.