Kako postaviti staging okolinu
za custom PHP web

Kod malih custom PHP projekata često postoji samo lokalna kopija i produkcija. To može raditi dok su promjene male, ali postaje rizično čim se uvode forme, CMS, baza, više stranica, novi asseti ili SEO promjene. Staging smanjuje taj rizik jer daje mjesto gdje se sve može provjeriti prije objave.

1. Što staging mora imitirati

Staging treba biti dovoljno sličan produkciji da uhvati realne probleme. Ako lokalno radite na jednoj PHP verziji, a produkcija ima drugu, staging treba pratiti produkciju. Ako produkcija ima HTTPS, redirect pravila, SMTP, cache i specifične pathove, staging treba imati barem usporedivu konfiguraciju.

2. Najjednostavnija staging struktura

Na shared hostingu staging može biti poddomena poput staging.example.com ili skrivena mapa. Poddomena je čišća jer ima zaseban document root, vlastiti config i manje rizika da se produkcijski i staging fileovi pomiješaju.

hosting-account/
├── public_html/              # produkcija
│   ├── index.php
│   ├── config.php
│   └── assets/
├── staging_html/             # staging
│   ├── index.php
│   ├── config.php
│   └── assets/
└── private/
    ├── backups/
    └── logs/

Ako staging mora biti u podmapi, obavezno provjerite base URL, canonical URL, asset putanje i rewrite pravila. Podmapa zna stvoriti probleme koji se ne pojavljuju na produkcijskom root URL-u.

3. Config po okolini mora biti odvojen

Produkcijski config ne smije biti pregazen staging configom. To vrijedi za bazu, SMTP, base URL, debug mode, assembly verziju i API ključeve. Najsigurnije je imati odvojene config datoteke po okolini i nikada ih ne uploadati naslijepo.

<?php

$env = getenv('APP_ENV') ?: 'production';

$configFile = __DIR__ . '/config.' . $env . '.php';

if (!is_file($configFile)) {
    throw new RuntimeException('Missing config for environment: ' . $env);
}

$config = require $configFile;

Ova disciplina se direktno nadovezuje na vodič kako organizirati PHP projekt bez frameworka, jer staging postaje puno lakši kada projekt ima jasno odvojene odgovornosti.

4. Staging mora biti zaštićen od indeksiranja

Staging stranice ne smiju završiti u Google indeksu. Ako staging kopira produkcijski sadržaj, može stvoriti dupli sadržaj, pogrešne canonical signale i neželjene rezultate pretraživanja. Najbolje je kombinirati pristupnu zaštitu i meta/noindex pravila.

<?php if ($config['env'] !== 'production'): ?>
    <meta name="robots" content="noindex, nofollow">
<?php endif; ?>

5. Baza na stagingu ne smije ugroziti produkciju

Staging treba imati vlastitu bazu. Nikada ne testirajte promjene na stagingu preko produkcijske baze, jer jedna kriva forma, migracija ili delete query može oštetiti stvarne podatke. Ako staging koristi kopiju produkcijske baze, pazite na osobne podatke i email slanje.

mysqldump --single-transaction -u prod_user -p prod_db \
  > /private/backups/prod-before-staging.sql

mysql -u staging_user -p staging_db \
  < /private/backups/prod-before-staging.sql

Ako baza sadrži osobne podatke, staging kopija bi trebala biti anonimizirana. To može biti jednostavno kao promjena email adresa i telefona u testne vrijednosti, ili ozbiljniji proces za veće sustave.

6. Email slanje na stagingu treba biti kontrolirano

Jedan od klasičnih staging problema je slučajno slanje emailova stvarnim korisnicima. Kontakt forme, CMS obavijesti, narudžbe ili newsletter testovi trebaju na stagingu ići na testnu adresu ili lokalni mail catcher, ne na stvarne primatelje.

<?php

function mail_recipient(string $realRecipient, array $config): string
{
    if ($config['env'] !== 'production') {
        return $config['mail']['test_recipient'];
    }

    return $realRecipient;
}

Ako koristite PHPMailer i SMTP, povezana tema je sigurna PHP kontakt forma preko SMTP-a.

7. Što provjeriti na stagingu prije produkcije

Staging nije samo mjesto gdje “otvorimo stranicu i izgleda dobro”. Treba imati checklistu koja pokriva funkcionalnost, SEO, performanse, assete i sigurnost. Što je checklist dosadniji, to je deploy mirniji.

Za assete i assembly verzije pogledajte i cache busting za CSS, JS i slike.

8. Deploy iz staginga na produkciju

Kada staging prođe provjeru, produkcijski deploy treba biti ciljano kopiranje promijenjenih datoteka, ne panični upload cijelog projekta. Posebno treba paziti na produkcijski config, upload mape i datoteke koje se generiraju na serveru.

9. Rollback plan mora postojati prije deploya

Staging smanjuje rizik, ali ga ne uklanja. Ako produkcija ipak pukne, treba znati što se vraća: zadnje stabilne datoteke, prethodni commit, backup baze ili samo korektivni hotfix. Rollback plan nije znak pesimizma, nego znak profesionalnog održavanja.

Detaljnije o tom dijelu opisano je u članku backup i rollback strategija za custom PHP web.

10. Kada staging nije dovoljan

Za jednostavan poslovni web staging je često dovoljan. Ali ako projekt ima puno korisnika, transakcije, web shop, rezervacije, naplatu ili kompleksne integracije, treba razmišljati i o automatiziranim testovima, migracijama baze, release folderima, monitoringu i jasnom incident procesu.

Zaključak: staging je mirniji put do produkcije

Dobra staging okolina daje vam prostor za provjeru prije nego promjene postanu javne. Kod custom PHP webova najvažnije je odvojiti config, bazu, upload mape i javni URL, zaštititi staging od indeksiranja, kontrolirati email slanje i imati checklistu koja se stvarno koristi.

Ako se staging poveže s dobrim backupom, rollback planom i cache busting disciplinom, deploy prestaje biti stresan događaj i postaje ponovljiv proces. To je posebno vrijedno kod webova koji trebaju dugoročno održavanje, SEO rast i stabilan rad bez iznenađenja.