Εγχειρίδιο: στόχοι ανάπτυξης (deploy) και ο δικός σας τομέας

Η ανάπτυξη στον δικό σου server σημαίνει να δώσεις σε έναν agent πρόσβαση παρόμοια με SSH σε ένα μηχάνημα που πληρώνεις, όπου ίσως ήδη φιλοξενούνται άλλα πράγματα. Αυτό είναι διαφορετικό επίπεδο εμπιστοσύνης από τη δημοσίευση σε δωρεάν subdomain, και η ρύθμιση το αντικατοπτρίζει — μερικά πεδία, συμπληρωμένα μία φορά, και μετά κάθε επόμενο build είναι ένα κουμπί. Να τι ρωτούν πραγματικά οι χρήστες πριν και μετά τη ρύθμιση ενός στόχου.

Τι χρειάζομαι για να δημιουργήσω έναν στόχο;

Πέντε πράγματα, στο Ρυθμίσεις → Ανάπτυξη:

1. Ένα όνομα που θα αναγνωρίζεις αργότερα — "prod-vps", "client-hostgator", ό,τι επιβιώνει σε ένα dropdown στις 11 το βράδυ
2. Host και port
3. Διαπιστευτήρια SFTP
4. Μια διαδρομή webroot

Χωρίς API tokens, χωρίς CLI για εγκατάσταση στον server, χωρίς cron job για επίβλεψη. Αν ο host σου παρέχει πρόσβαση SFTP — που καλύπτει σχεδόν κάθε shared host, κάθε VPS, κάθε managed WordPress box — τελειώνεις σε περίπου δύο λεπτά.

Κωδικός ή κλειδί;

Κλειδί, αν ο host σου το υποστηρίζει. Οι κωδικοί δουλεύουν μια χαρά και τους αποθηκεύουμε με εμβέλεια στον λογαριασμό σου, αλλά ένα κλειδί είναι ένα μυστικό λιγότερο οπουδήποτε — η διαφορά μεταξύ «ανάκληση ενός κλειδιού» και «επαναφορά κωδικού παντού όπου τυχόν επαναχρησιμοποιήθηκε» αν κάτι πάει στραβά αργότερα. Πολλές φθηνές shared-hosting ρυθμίσεις SFTP προσφέρουν μόνο έλεγχο ταυτότητας με κωδικό, και αυτό είναι επίσης εντάξει. Απλά μην επαναχρησιμοποιήσεις αυτόν τον κωδικό πουθενά αλλού.

Πώς βρίσκω τη σωστή διαδρομή webroot;

Αυτό είναι το πεδίο που κάνουν λάθος οι περισσότεροι την πρώτη φορά, γιατί η λάθος απάντηση εξακολουθεί να φαίνεται εύλογη. Δεν είναι ο home φάκελός σου, δεν είναι /var/www — είναι ο ακριβής φάκελος από τον οποίο έχει ρυθμιστεί ο web server σου να σερβίρει.

Αν δεν είσαι σίγουρος/η, ρίξε ένα δοκιμαστικό test.txt στον φάκελο που νομίζεις ότι είναι σωστός χρησιμοποιώντας οποιονδήποτε client SFTP, και μετά έλεγξε αν φορτώνει στο yoursite.com/test.txt. Κάν' το λάθος και η ανάπτυξη θα εξακολουθήσει να αναφέρει επιτυχία — ο agent γράφει πιστά τα αρχεία στον λάθος φάκελο, και μένεις να κοιτάζεις ένα ζωντανό site που δεν έχει αλλάξει, αναρωτούμενος/η γιατί.

Μπορεί ένας στόχος να καλύπτει περισσότερα από ένα domains;

Ναι, και αυτό είναι το κομμάτι που εξοικονομεί πραγματικό χρόνο μόλις περάσεις το πρώτο σου site. Ένας στόχος είναι ένας server και ένα σύνολο διαπιστευτηρίων — δεν είναι δεμένος σε ένα μόνο domain. Στη Διαχείριση Domain συνδέεις κάθε domain σε έναν στόχο με δική του παράκαμψη webroot. Τρέχεις τρία sites από ένα VPS με Nginx server blocks;

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

Ένας στόχος, τρεις συνδέσεις. Δεν εισάγεις ξανά κωδικό SSH τρεις φορές, και δεν συντηρείς τρεις σχεδόν πανομοιότυπους στόχους που αποκλίνουν την ημέρα που περιστρέφεις ένα κλειδί και ξεχνάς έναν από αυτούς. Κάνε κλικ στην ανάπτυξη σε οποιοδήποτε από τα τρία domains και ήδη ξέρει ποιον server και ποιον φάκελο — δεν επιλέγεις τίποτα τη στιγμή της ανάπτυξης.

Τι κάνει πραγματικά ο agent όταν συνδέεται;

Πρώτα, κοιτάζει γύρω — μόνο για ανάγνωση, τίποτα δεν γράφεται ακόμα. Αυτή η επιθεώρηση ελέγχει για:

• Έναν κενό φάκελο
• Μια προηγούμενη έκδοση ακριβώς αυτού του build
• Μια παλιά εγκατάσταση WordPress
• Ένα placeholder "σύντομα κοντά σας" που άφησε ο host σου εκεί εξ ορισμού

Αυτό καθορίζει τη στρατηγική. Ένα κενό webroot παίρνει μια απλή μεταφόρτωση. Ένα webroot με κάτι ήδη μέσα αντιμετωπίζεται πιο προσεκτικά, γιατί πολλές πραγματικές ρυθμίσεις έχουν πράγματα να ζουν δίπλα στο site που δεν πρέπει να εξαφανιστούν:

• A .well-known φάκελος για επικύρωση SSL
• Ένας uploads φάκελος που κανείς δεν έβαλε σε git
• A wp-config.php κανείς δεν θέλει να το πειράξει

Η δουλειά εδώ μοιάζει περισσότερο με «να καταλάβεις τι άλλαξε και να το συμβιβάσεις» παρά με «σβήσε και αντικατέστησε».

Στη συνέχεια, πριν αντικατασταθεί έστω και ένα byte, το υπάρχον webroot καταγράφεται ως έκδοση στον δικό σου host. Όχι μια εγγραφή βάσης δεδομένων, όχι ένα diff που υπολογίζουμε και ελπίζουμε ότι είναι σωστό — ένα πραγματικό στιγμιότυπο του τι υπήρχε εκεί. Αυτό έχει τη μεγαλύτερη σημασία στην πρώτη ανάπτυξη σε οποιονδήποτε στόχο, γιατί εκείνη η ανάπτυξη πάντα προσγειώνεται πάνω σε κάτι, ακόμα κι αν αυτό το κάτι είναι το τίποτα. Κενός φάκελος, κενό στιγμιότυπο. Πενταετές στατικό site που κανείς δεν θυμάται ότι έφτιαξε — διατηρείται ακριβώς όπως ήταν, δωρεάν, πριν καν αγγιχτεί. Αυτή η πρώτη ανάπτυξη είναι επίσης εκείνη για την οποία είσαι λιγότερο σίγουρος/η, οπότε είναι εκείνη όπου αυτό έχει τη μεγαλύτερη σημασία.

Ανεβάζει τον πηγαίο κώδικα ή το χτισμένο site;

Χτισμένος ιστότοπος, πάντα. Για έναν στατικό ιστότοπο αυτό είναι οι παραγόμενες σελίδες. Για ένα build framework — Next.js, Vite, ό,τι απαιτεί ο τύπος του ιστότοπου — είναι το μεταγλωττισμένο αποτέλεσμα, ο dist ή build φάκελος, ποτέ το δέντρο πηγαίου κώδικα. Πιστεύω ότι αυτή είναι η σωστή επιλογή, παρόλο που σημαίνει ότι δεν μπορείς να συνδεθείς μέσω SSH και να τρέξεις npm run dev στο ό,τι βρίσκεται στον διακομιστή. Το ανέβασμα πηγαίου κώδικα θα σήμαινε ότι ο webroot παραγωγής χρειάζεται περιβάλλον εκτέλεσης Node και εργαλεία build μόνο και μόνο για να σερβίρει HTML — μετατρέποντας ένα shared-hosting μηχάνημα που ποτέ δεν προοριζόταν να τρέχει build pipeline σε ένα τέτοιο, και μετατρέποντας κάθε deploy σε "ελπίζω ο διακομιστής να έχει αρκετή μνήμη για να ολοκληρώσει npm install." Η αποστολή μόνο του μεταγλωττισμένου αποτελέσματος διατηρεί τον webroot ακριβώς όπως το περιμένει ένας static file server. Βαρετό. Το βαρετό είναι αυτό που θέλεις στις 2 τα ξημερώματα όταν κάτι πάει στραβά και κοιτάς εκείνον τον φάκελο προσπαθώντας να καταλάβεις τι πραγματικά σερβίρεται.

Πώς ξέρω ότι μια ανάπτυξη λειτούργησε πράγματι;

Μετά το ανέβασμα, ο agent επισκέπτεται το ζωντανό URL και ελέγχει αν επιλύεται σωστά — όχι 500, όχι κενή σελίδα. Ό,τι βρει, μαζί με οτιδήποτε παρατήρησε κατά την επιθεώρηση για το οποίο θέλει τη γνώμη σου ("αυτός ο webroot έχει έναν φάκελο wp-content που άφησα ανέγγιχτο, επιβεβαίωσε ότι αυτό είναι αναμενόμενο"), καταλήγει στο νήμα συνομιλίας του build. Αυτό είναι το μοτίβο σε ολόκληρη αυτή την πλατφόρμα: καμία σιωπηλή επιτυχία, καμία σιωπηλή αποτυχία που καταλήγει σε ticket υποστήριξης. Ο agent σου λέει τι είδε και τι αποφάσισε, στο ίδιο νήμα όπου ζήτησες το build.

Τι υπάρχει πραγματικά στο ιστορικό εκδόσεων;

Κάθε ανάπτυξη προσθέτει μια έκδοση — όχι μόνο η πρώτη. Οπότε το ιστορικό δεν είναι τα builds σου σχεδιασμένα πάνω σε μια αφηρημένη χρονογραμμή· είναι η κυριολεκτική ακολουθία του τι σερβιρίστηκε από εκείνο το webroot, με τη σειρά, ξεκινώντας από ό,τι υπήρχε εκεί πριν εμφανιστείς. Η έκδοση ένα είναι πάντα αυτή η κατάσταση πριν από την πλατφόρμα, καταγεγραμμένη αυτόματα. Δεν χρειάζεται να το σκεφτείς.

Τι επαναφέρει πραγματικά η επαναφορά;

Την προηγούμενη ζωντανή έκδοση, ακριβώς — όχι επανεκτέλεση παλιού build, όχι προσέγγιση. Τα πραγματικά αρχεία που σέρβιραν κίνηση πριν. Αυτή είναι μια σημαντικά ισχυρότερη εγγύηση από τις περισσότερες λειτουργίες «rollback» που έχω χρησιμοποιήσει αλλού, που συνήθως σημαίνουν «επανάπτυξη από παλιό commit» και σιωπηρά υποθέτουν ότι η διαδικασία build σου είναι ντετερμινιστική και το περιβάλλον σου δεν έχει αλλάξει από τότε. Εδώ η επαναφορά είναι μια αποκατάσταση ενός γνωστού-καλού στιγμιότυπου, γι' αυτό είναι ασφαλές να την επικαλεστείς υπό πίεση — δεν αναρωτιέσαι αν το rollback μπορεί να συμπεριφερθεί διαφορετικά από αυτό στο οποίο επαναφέρεται.

Και η στιγμή που πραγματικά τη χρειάζεσαι δεν είναι ποτέ ήρεμη· είναι «το νέο build χάλασε το checkout και η κίνηση είναι ζωντανή αυτή τη στιγμή».

Ένα κλικ, η προηγούμενη έκδοση επαναφέρεται, τέλος. Η λογική πίσω από τη μεταχείριση αυτού ως πρωτεύουσας λειτουργίας αντί για ύστερη σκέψη βρίσκεται στο Επανάληψη χωρίς φόβο — αξίζει να το διαβάσεις μια φορά, πριν το χρειαστείς. Και το ιστορικό και το χειριστήριο επαναφοράς βρίσκονται στην κάρτα του build και στη δική της προβολή ιστορικού του στόχου.

Κάνει αυτό backup και τη βάση δεδομένων μου;

Όχι, και προτιμώ να το πω ξεκάθαρα παρά να αφήσω κάποιον να το υποθέσει. Το ιστορικό εκδόσεων στον host καλύπτει ό,τι έβαλε αυτή η διοχέτευση ανάπτυξης στο webroot. Αν το site σου έχει βάση δεδομένων, ή uploads χρηστών, ή οτιδήποτε άλλο αλλάζει εκτός αναπτύξεων, αυτό είναι ένα εντελώς ξεχωριστό ζήτημα — η επαναφορά δεν το αγγίζει και δεν πρέπει να εκληφθεί ως στρατηγική backup που το καλύπτει.