---
title: "X. Ισοτιμία dev/prod"
source: Twelve-Factor App
source_url: https://github.com/heroku/12factor
licence: MIT
domain: engineering
subdomain: 12factor
date_added: 2026-04-25
---

## X. Ισοτιμία dev/prod
### Κράτησε τα περιβάλλοντα υλοποίησης, ελέγχου και παραγωγής όσο πιο όμοια γίνεται

Ιστορικά, έχουν υπάρξει μεγάλα χάσματα μεταξύ υλοποίησης (development) (ο προγραμματιστής να κάνει αλλαγές σε πραγματικό χρόνο σε μία τοπική [ανάπτυξη](./codebase) της εφαρμογής) και της παραγωγής (production) (μία εκτελούμενη ανάπτυξη της εφαρμογής προσβάσιμη μόνο από τελικούς χρήστες).  Αυτά τα χάσματα εκδηλώνονται σε τρία σημεία:

* **Το χρονικό χάσμα**: Ένας προγραμματιστής μπορεί να δουλέυει σε ένα κώδικα που παίρνει μέρες, εβδομάδες, ή ακόμα και μήνες να φτάσει στην παραγωγή.
* **Το χάσμα προσωπικού**: Οι προγραμματιστές (developers) γράφουν κώδικα, οι επιχειρησιακοί μηχανικοί (ops engineers) τον αναπτύσσουν.
* **Το εργαλειακό χάσμα**: Οι προγραμματιστές μπορεί να χρησιμοποιούν εργαλεία όπως το Nginx, την SQLite, και το OS X, αλλά η αναπτύξη της παραγωγής χρησιμοποιεί το Apache, τη MySQL, και το Linux.

**Η εφαρμογή δώδεκα παραγόντων είναι σχεδιασμένη για [συνεχή αναπτύξη (continuous deployment)](http://avc.com/2011/02/continuous-deployment/) με το να κρατάει το χάσμα μεταξύ υλοποίησης (development) και παραγωγής (production) μικρό.**  Κοιτώντας τα τρία χάσματα που περιγράψαμε παραπάνω:

* Μείωσε το χρονικό χάσμα: ένας προγραμματιστής μπορεί να γράψει κώδικα και να τον αναπτύξει μερικές ώρες ή ακόμα και μερικά λεπτά αργότερα.
* Μείωσε το χάσμα προσωπικού: οι προγραμματιστές που έγραψαν τον κώδικα ασχολούνται στενά με την ανάπτυξή του και παρακολουθούν την συμπεριφορά του στην παραγωγή.
* Μείωσε το εργαλειακό χάσμα: κράτησε τα περιβάλλοντα υλοποίησης (development) και παραγωγής (production) όσο πιο όμοια γίνεται.

Συνοψίζοντας τα παραπάνω σε ένα πίνακα:

<table>
  <tr>
    <th></th>
    <th>Παραδοσιακή εφαρμογή</th>
    <th>Εφαρμογή δώδεκα παραγόντων</th>
  </tr>
  <tr>
    <th>Χρόνος μεταξύ αναπτύξεων</th>
    <td>Εβδομάδες</td>
    <td>Ώρες</td>
  </tr>
  <tr>
    <th>Συγγραφείς κώδικα ή αναπτυκτές του κώδικα</th>
    <td>Διαφορετικοί άνθρωποι</td>
    <td>Ίδιοι άνθρωποι</td>
  </tr>
  <tr>
    <th>Περιβάλλοντα υλοποίησης (dev) ή παραγωγής (production)</th>
    <td>Αποκλίνοντα</td>
    <td>Όσο πιο όμοια γίνεται</td>
  </tr>
</table>

Οι [υπηρεσίες υποστήριξης](./backing-services), όπως η βάση δεδομένων (database) της εφαρμογής, το σύστημα ουρών (queueing system), ή η προσωρινή μνήμη (cache), είναι ένας τόπος όπου η ισοτιμία dev/prod είναι σημαντική.  Πολλές γλώσσες προγραμματισμού προσφέρουν βιβλιοθήκες οι οποίες απλοποιούν την πρόσβαση στην υπηρεσία υποστήριξης, συμπεριλαμβανομένων *προσαρμογέων* (*adapters*) για διάφορους τύπους υπηρεσιών.  Μερικά παραδείγματα περιέχονται στον παρακάτω πίνακα.

<table>
  <tr>
    <th>Τύπος</th>
    <th>Γλώσσα Προγραμματισμού</th>
    <th>Βιβλιοθήκη</th>
    <th>Προσαρμογείς</th>
  </tr>
  <tr>
    <td>Βάση δεδομένων</td>
    <td>Ruby/Rails</td>
    <td>ActiveRecord</td>
    <td>MySQL, PostgreSQL, SQLite</td>
  </tr>
  <tr>
    <td>Ουρά εργασιών</td>
    <td>Python/Django</td>
    <td>Celery</td>
    <td>RabbitMQ, Beanstalkd, Redis</td>
  </tr>
  <tr>
    <td>Προσωρινή μνήμη</td>
    <td>Ruby/Rails</td>
    <td>ActiveSupport::Cache</td>
    <td>Memory, filesystem, Memcached</td>
  </tr>
</table>

Οι προγραμματιστές μερικές φορές βρίσκουν πολύ ελκυστικό να χρησιμοποιήσουν μια ελαφρά υπηρεσία υποστήριξης στο τοπικό περιβάλλον ανάπτυξής τους, ενώ μια πιο στιβαρή και εύρωστη υπηρεσία υποστήριξης θα χρησιμοποιηθεί στην παραγωγή.  Για παράδειγμα, χρησιμοποιώντας την SQLite τοπικά και την PostgreSQL στην παραγωγή, ή την τοπική μνήμη διεργασίας για προσωρινή μνήμη κατά την υλοποίηση και το Memcached στην παραγωγή.

**Ο προγραμματιστής δώδεκα παραγόντων αντιστέκεται στην ορμή να χρησιμοποιήσει διαφορετικές υπηρεσίες υποστήριξης μεταξύ υλοποίησης και παραγωγής**, ακόμα και όταν οι προσαρμογείς θεωρητικά μπορούν να αφαιρέσουν τις επιμέρους διαφορές στις υπηρεσίες υποστήριξης.  Οι διαφορές μεταξύ υπηρεσιών υποστήριξης σημαίνουν ότι μικρές ασυμβατότητες ανακύπτουν, που προκαλούν τον κώδικα που λειτουργούσε και πέρναγε τα τεστ στην υλοποίηση ή στον έλεγχο να αποτυγχάνει στην παραγωγή.  Αυτού του είδους τα σφάλματα δημιουργούν τριβή η οποία είναι αντικίνητρο στην συνεχή ανάπτυξη (continuous deployment).  Το κόστος αυτής της τριβής και της επακόλουθης μείωσης της συνεχούς ανάπτυξης είναι εξαιρετικά υψηλό όταν ληφθεί υπόψη η συσσώρευσή του κατά την διάρκεια του χρόνου ζωής της εφαρμογής.

Οι ελαφρές τοπικές υπηρεσίες είναι λιγότερο ελκυστικές από ότι ήταν κάποτε.  Οι μοντέρνες υπηρεσίες υποστήριξης όπως το Memcached, η PostgreSQL, και το RabbitMQ δεν είναι δύσκολο να εγκατασταθούν και να τρέξουν χάριν στα μοντέρνα συστήματα πακεταρίσματος (modern packaging systems), όπως το [Homebrew](http://mxcl.github.com/homebrew/) και το [apt-get](https://help.ubuntu.com/community/AptGet/Howto).  Εναλλακτικά, τα εργαλεία δηλωμένων παροχών (declarative provisioning tools) όπως το [Chef](http://www.opscode.com/chef/) και το [Puppet](http://docs.puppetlabs.com/) συνδυασμένα με ελαφρά εικονικά περιβάλλοντα (light-weight virtual environments) όπως το [Docker](https://www.docker.com/) και το [Vagrant](http://vagrantup.com/) επιτρέπουν στους προγραμματιστές να τρέξουν τοπικά περιβάλλοντα τα οποία προσομοιάζουν κατά πολύ τα περιβάλλοντα παραγωγής. Το κόστος εγκατάστασης και χρήσης αυτών των συστημάτων είναι χαμηλό συγκρινόμενο με το πλεονέκτημα της ισοτιμίας dev/prod και της συνεχούς αναπτύξεως.

Οι προσαρμογείς στις διαφορετικές υπηρεσίες υποστήριξης είναι ακόμα χρήσιμοι, επειδή η μετάβαση σε νέες υπηρεσίες υποστήριξης γίνεται σχετικά  αβασάνιστα.  Αλλά όλες οι αναπτύξεις (deploys) της εφαρμογής (περιβάλλοντα υλοποίησης, ελέγχου, παραγωγής) θα πρέπει να χρησιμοποιούν τον ίδιο τύπο και έκδοση για κάθε μια από τις υπηρεσίες υποστήριξης.
