După primele update-uri, apar întrebările: „Ce `game` rulează acum? Cel de marți sau cel de joi? Clientul jucătorilor e cel nou? Modificarea din baza de date a intrat odată cu binarul sau după?”. Dacă nu poți răspunde în 30 de secunde, o problemă mică devine o seară lungă. Soluția e simplă și nu cere programare: **fiecare release are un nume, un dosar și o fișă**.
2026.11.02-1), pui într-un singur dosar tot ce intră în ea (binare, questuri, fișiere TXT, scripturi SQL, client), notezi amprentele sha256 și ce s-a schimbat, testezi pe serverul de test și păstrezi versiunea anterioară pregătită pentru rollback.Nivel: Avansat. Ce trebuie să știi înainte: cum pui binarele pe server, modificări sigure și rollback, mentenanța fără pierderi și backup.
Cuvinte pe care le vei întâlni
| Cuvânt | Ce înseamnă |
|---|---|
| Versiune | O stare anume a serverului, cu nume. „Ce rulează acum.” |
| Release | Momentul în care pui o versiune nouă pe live, plus tot ce o însoțește. |
| Manifest | Fișa versiunii: ce fișiere conține, amprentele lor, ce s-a schimbat. |
| Migrare SQL | Un script care schimbă baza de date (o coloană nouă, o valoare). |
| Regresie | Ceva care mergea și s-a stricat după update. |
Nu te baza pe „version.txt”
Multe pachete scriu la pornire un fișier de versiune. În pachetul verificat, fiecare core creează version.txt cu textul game revision: 40250. Dar în sursă acest text e scris fix în cod, în version.cpp. Orice game compilat din acea sursă scrie același număr, indiferent ce ai schimbat. Deci nu-ți spune nimic despre build-ul tău. Singura dovadă sigură e amprenta sha256.
Pasul 1: Alege un nume simplu
Cel mai ușor: data plus un număr de ordine.
2026.11.02-1 primul release din 2 noiembrie
2026.11.02-2 al doilea, în aceeași ziFolosește același nume peste tot: în dosar, în jurnalul de modificări, în anunțul pentru jucători.
Pasul 2: Construiește dosarul de release
Pe serverul de test, adună totul într-un singur loc:
/usr/home/releases/2026.11.02-1/
game binarul compilat
db doar dacă s-a schimbat
quest/ fișierele .quest modificate
conf/ item_proto, mob_proto etc. modificate
sql/ scripturile de migrare, cu varianta de anulare
client/ executabilul și fișierele de client schimbate
MANIFEST.txt fișa versiuniiPune doar ce s-a schimbat față de versiunea anterioară. Sursa din care ai compilat o păstrezi separat (o copie sau un commit Git), cu numele versiunii.
Pasul 3: Scrie manifestul
Generează amprentele:
cd /usr/home/releases/2026.11.02-1
sha256 game db >> MANIFEST.txt>> adaugă rezultatul la finalul fișierului, fără să șteargă ce era. Apoi completează cu mâna:
Versiune: 2026.11.02-1
Sursa: copie sursa-2026-11-02 (sau commit Git)
Compilat pe: server de test, FreeBSD i386, clang
Schimbari:
- mesajul comenzii /who tradus
- drop nou la boss-ul X (mob_drop_item)
Baza de date: fara schimbari
Client: fara schimbari
Testat: login, drop, cufar, NPC, trade, depozit, schimbare canal, relog
Rollback: release 2026.10.28-1Rândul „Rollback” e cel mai important: spune la ce versiune revii dacă ceva merge prost.
Pasul 4: Ordinea unui release
- Testezi pe serverul de test exact conținutul dosarului.
- Faci backup coerent al bazei de date și al serverfiles (vezi backup).
- Anunți mentenanța și oprești serverul corect.
- Rulezi migrațiile SQL, dacă există.
- Pui binarele, questurile și fișierele, după procedura de deploy.
- Pornești și verifici pe fiecare canal.
- Publici clientul nou, dacă e cazul, prin autopatcher.
- Scrii în jurnal: „2026.11.02-1 pe live la ora ...”.
Ce testezi după release
Un login reușit nu e suficient. Regresiile apar cel mai des la:
| Zonă | Ce faci |
|---|---|
| Inventar și depozit | Muți iteme, închizi, redeschizi, relogezi |
| Comerț (trade) | Un schimb complet între două conturi de test |
| Iteme cu bonusuri și pietre | Verifici că își păstrează valorile după relog |
| Hărți | Te teleportezi pe câteva hărți și schimbi canalul |
| Questuri | Un quest în desfășurare continuă corect după restart |
| Sisteme adăugate de tine | Fiecare, pe rând |
Pentru detalii, vezi testarea trade, depozit și inventar după update.
Rollback care ține cont și de baza de date
Să pui la loc binarul vechi durează un minut. Dar dacă release-ul a schimbat și baza de date, binarul vechi poate să nu mai înțeleagă datele noi. De aceea:
- fiecare script SQL vine cu perechea lui de anulare, testată pe test;
- dacă anularea nu e posibilă, rollback-ul înseamnă restaurarea backup-ului, iar jucătorii pierd progresul de după backup. Asta trebuie decis înainte de release, nu în timpul problemei.
Vezi și restaurarea unui backup pe serverul de test.
Greșeli des întâlnite
- Release-uri fără nume. Nu mai știi ce rulează.
- Mai multe schimbări mari într-un singur release. Dacă apare o problemă, nu știi care e vinovata.
- Ștergi release-ul vechi imediat după cel nou. Păstrează măcar ultimele două care au mers.
- Uiți clientul. Serverul e nou, jucătorii au clientul vechi.
- Testezi pe test altceva decât pui pe live. Dosarul de release e unul singur, același pentru amândouă.
Întrebări frecvente
Trebuie să folosesc Git?
Nu e obligatoriu, dar ajută mult la sursă și la fișierele text: vezi exact ce s-a schimbat între versiuni. Nu pune niciodată în Git parole, fișiere CONFIG reale sau dump-uri de bază de date.
Cât de des fac release-uri?
Cât de rar poți, cu cât mai puține schimbări în fiecare. Mai bine două release-uri mici decât unul mare.
Ce fac cu reparațiile urgente?
Tot un release, doar mai mic: 2026.11.02-2, cu manifestul lui. Urgența nu e un motiv să sari peste test și backup.
Ce urmează
Mergi la portarea sursei pe un FreeBSD modern. Toate lecțiile sunt în lista tutorialelor Metin2.
Server Metin2 gata de joc
Găzduire Metin2 în România, cu instalare de serverfiles, bază de date MySQL și protecție Anti-DDoS inclusă.