Αυτές είναι οι πιο αποτελεσματικές στρατηγικές δοκιμών μικροϋπηρεσιών, σύμφωνα με τους ειδικούς

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

Αλλά πρώτα, μια γρήγορη ιστορία.

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

Συζήτηση για ταραχώδη.

Η προσέγγιση που ακολουθήσαμε ήταν να τρέξουμε τα πάντα τοπικά. Αυτό σήμαινε, σε οποιαδήποτε δεδομένη στιγμή όταν θέλω να εκτελέσω δοκιμές από άκρο σε άκρο, θα χρειαζόμουν να ακολουθήσω τα ακόλουθα πέντε βήματα για καθένα από τα επτά μικροσυστήματα:

  1. Βεβαιωθείτε ότι ήμουν στο σωστό κλάδο κώδικα (είτε το κύριο είτε το χαρακτηριστικό_xyz)
  2. Τραβήξτε τον τελευταίο κωδικό για αυτόν τον κλάδο
  3. Βεβαιωθείτε ότι όλες οι εξαρτήσεις ήταν ενημερωμένες
  4. Εκτελέστε νέες μετεγκαταστάσεις βάσης δεδομένων
  5. Ξεκινήστε την υπηρεσία

Αυτή ήταν απλώς μια βασική απαίτηση για να είναι δυνατή η εκτέλεση των δοκιμών. Συχνά φορές, θα ξεχάσω να εκτελέσω ένα από αυτά τα βήματα για μια υπηρεσία και να αφιερώσω 10-15 λεπτά για να διορθώσω το πρόβλημα. Μόλις είχα επιτέλους όλες τις υπηρεσίες χαρούμενες και τρέχουσες, θα μπορούσα τότε να αρχίσω να ξεκινάω τη δοκιμαστική σουίτα. Αυτή η εμπειρία με έκανε να χάσω τις μέρες της δοκιμής ενός μεγάλου μονόλιθου.

Ναι, ανακάλυψα ότι η δοκιμή μικροϋπηρεσίας από άκρο σε άκρο είναι δύσκολη - και γίνεται εκθετικά δυσκολότερη με κάθε νέα υπηρεσία που εισάγετε. Αλλά μην φοβάστε, γιατί υπάρχουν τρόποι για να κάνετε ευκολότερη τη δοκιμή μικροσυσκευών. Έχω μιλήσει σε αρκετούς CTO για το πώς βρήκαν τους δικούς τους δημιουργικούς τρόπους αντιμετώπισης αυτού του περίπλοκου ζητήματος.

Συνήθεις μέθοδοι δοκιμής μικροϋπηρεσίας

Δοκιμή μονάδας

Μια μικροσυσκευή μπορεί να είναι μικρότερη εξ ορισμού, αλλά με τη δοκιμή μονάδας, μπορείτε να πάρετε ακόμη πιο λεπτομερή. Ένα τεστ μονάδας εστιάζει στο μικρότερο μέρος ενός δοκιμαστέου λογισμικού για να εξακριβώσει εάν αυτό το στοιχείο λειτουργεί όπως θα έπρεπε. Ο διάσημος μηχανικός λογισμικού, ο συγγραφέας και ο διεθνής ομιλητής Martin Fowler χωρίζει τις δοκιμές μονάδων σε δύο κατηγορίες:

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

Ενώ αυτές οι στρατηγικές δοκιμών μονάδων είναι διαφορετικές, ο Fowler υποστηρίζει ότι δεν ανταγωνίζονται - μπορούν να χρησιμοποιηθούν ταυτόχρονα για την επίλυση διαφορετικών προβλημάτων δοκιμών.

Κατά τη διάρκεια μιας συζήτησης με τον David Strauss, CTO του Πάνθεον, ο David μου είπε ότι «η ευκαιρία είναι ότι οι Microservices είναι πολύ απλές για να κάνουν πραγματικά δοκιμές μονάδας».

Δοκιμή ολοκλήρωσης

Με τις δοκιμές ενσωμάτωσης, κάνετε αυτό που ακούγεται όπως κάνετε: δοκιμάστε τις διαδρομές επικοινωνίας και τις αλληλεπιδράσεις μεταξύ των στοιχείων για να εντοπίσετε προβλήματα. Σύμφωνα με τον Fowler, ένα τεστ ολοκλήρωσης «ασκεί διαδρομές επικοινωνίας μέσω του υποσυστήματος για να ελέγξει για τυχόν εσφαλμένες παραδοχές που έχει κάθε ενότητα σχετικά με τον τρόπο αλληλεπίδρασης με τους συναδέλφους της».

Μια δοκιμή ενοποίησης συνήθως ελέγχει τις αλληλεπιδράσεις μεταξύ της μικροσυσκευής και των εξωτερικών υπηρεσιών, όπως μια άλλη υπηρεσία μικροϋπολογιστών ή δεδομένων.

Ο Pawel Ledwoń, επικεφαλής της πλατφόρμας στο Pusher, με πληροφόρησε ότι η ομάδα του «κλίνει προς τις δοκιμές ολοκλήρωσης. Οι δοκιμές μονάδας εξακολουθούν να είναι χρήσιμες για ορισμένες αφαιρέσεις, αλλά για χαρακτηριστικά που αντιμετωπίζουν οι χρήστες είναι δύσκολο να παραπλανήσουν ή να παρακάμψουν σημαντικά μέρη του συστήματος. "

Δεν ήταν όλοι όσοι μίλησα ήταν οπαδός της διαδικασίας. Αξίζει να σημειωθεί ότι, για παράδειγμα, η δοκιμασία ενσωμάτωσης του Mosquera στο θέμα της ολοκλήρωσης:

Η δοκιμή ενοποίησης είναι πολύ επιρρεπής σε σφάλματα και δαπανηρή, σε όρους ανθρωποώρες. Το ROI δεν είναι εκεί. Κάθε ατομική δοκιμή ενσωμάτωσης προσφέρει μικρή οριακή κάλυψη περιπτώσεων χρήσης.

Δοκιμή από άκρο σε άκρο

Τελευταίο αλλά όχι λιγότερο σημαντικό είναι η δοκιμή end-to-end, η οποία - όπως αναφέρθηκε προηγουμένως - μπορεί να είναι μια δύσκολη εργασία. Αυτό συμβαίνει επειδή περιλαμβάνει τη δοκιμή κάθε κινούμενου μέρους της μικροσυστήματος, διασφαλίζοντας ότι μπορεί να επιτύχει τους στόχους για τους οποίους δημιουργήσατε.

Ο Fowler έγραψε τα εξής:

Οι δοκιμές end-to-end ενδέχεται επίσης να πρέπει να λαμβάνουν υπόψη την ασύγχρονη λειτουργία του συστήματος, είτε στο GUI είτε λόγω ασύγχρονων διεργασιών backend μεταξύ των υπηρεσιών.

Στη συνέχεια εξηγεί πώς αυτοί οι παράγοντες μπορούν να οδηγήσουν σε «αστάθεια, υπερβολικό χρόνο δοκιμής και επιπλέον κόστος συντήρησης της δοκιμαστικής σουίτας».

Η καλύτερη συμβουλή που μπορώ να δώσω όταν πρόκειται για δοκιμή από άκρο σε άκρο είναι να περιορίσω τον αριθμό των φορών που το επιχειρείτε ανά υπηρεσία. Μια υγιής ισορροπία μεταξύ των άλλων στρατηγικών δοκιμών μικροϋπηρεσίας που αναφέρθηκαν - όπως η δοκιμή μονάδας και η δοκιμή ενοποίησης - θα σας βοηθήσουν να εξαλείψετε μικρότερα ζητήματα.

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

Οι προκλήσεις της δοκιμής μικροϋπηρεσιών

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

Ακολουθούν μερικές βασικές προκλήσεις που σχετίζονται με τη δοκιμή μικροσυσκευών:

  • Διαθεσιμότητα: Δεδομένου ότι διαφορετικές ομάδες μπορεί να διαχειρίζονται τις δικές τους μικροσυσκευές, διασφαλίζοντας τη διαθεσιμότητα μιας μικρο-υπηρεσίας (ή, ακόμη χειρότερα, προσπαθώντας να βρούμε μια στιγμή που όλες οι μικροϋπηρεσίες είναι διαθέσιμες ταυτόχρονα), είναι δύσκολο.
  • Κατακερματισμένος και ολιστικός έλεγχος: Οι μικροϋπηρεσίες είναι σχεδιασμένες για να λειτουργούν μόνες τους και μαζί με άλλες χαλαρά συνδεδεμένες υπηρεσίες. Αυτό σημαίνει ότι οι προγραμματιστές πρέπει να δοκιμάσουν κάθε στοιχείο ξεχωριστά, καθώς και να δοκιμάσουν τα πάντα μαζί.
  • Κενά γνώσης: Ιδιαίτερα με τις δοκιμές ολοκλήρωσης (τις οποίες θα εξετάσουμε αργότερα σε αυτό το άρθρο), όποιος διεξάγει τις δοκιμές θα πρέπει να έχει μια ισχυρή κατανόηση κάθε υπηρεσίας προκειμένου να γράψει αποτελεσματικά τις δοκιμαστικές περιπτώσεις.

Σύμφωνα με τον Oleksiy Kovyrin, επικεφαλής του Swiftype SRE στο Elastic,

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

Ο Stefan Zier, αρχιτέκτονας της Sumo Logic, μου επανέλαβε επίσης ότι η δοκιμή μικροεξυπηρέτησης είναι πράγματι «πολύ, πολύ δύσκολη».

«Ειδικά όταν προχωράτε σε πιο συνεχή ανάπτυξη. Έχουμε επενδύσει και συνεχίζουμε να επενδύουμε αρκετά σε δοκιμές ενοποίησης, δοκιμές μονάδων και θα κάναμε πολλά περισσότερα αν είχαμε τους ανθρώπους να το κάνουν », μου είπε ο Zier.

Με αυτά τα λόγια, παραδέχτηκε ότι, σε ορισμένα στάδια, όταν η Sumo Logic θέλει να δοκιμάσει τις υπηρεσίες τους ολιστικά, «λίγο πολύ [ολόκληρη] η εταιρεία [γίνεται] μια ομάδα διασφάλισης ποιότητας υπό μια έννοια.»

Λύση: Πέντε στρατηγικές δοκιμών microservice για νεοσύστατες επιχειρήσεις

Ναι, η δοκιμή μικροσυσκευών μπορεί να είναι δύσκολη, αλλά δεδομένου του συνόλου των πλεονεκτημάτων των μικροϋπηρεσιών, η παραίτησή τους λόγω των προκλήσεων δοκιμής δεν είναι ο σωστός δρόμος. Για να αντιμετωπίσω αυτές τις προκλήσεις, έλαβα πληροφορίες από αρκετούς CTO και αποστάχνω πέντε στρατηγικές που χρησιμοποίησαν για να προσεγγίσουν επιτυχώς τον έλεγχο των μικροϋπηρεσιών.

1. Η πρώτη στρατηγική τεκμηρίωσης

Ο Chris McFadden, VP του Engineering Sparkpost, συνόψισε αρκετά καλά την πρώτη στρατηγική τεκμηρίωσης κατά τη διάρκεια της συζήτησής μας:

Ακολουθούμε μια πρώτη προσέγγιση τεκμηρίωσης, οπότε όλα τα έγγραφα τεκμηριώνονται στο GitHub Τα έγγραφα API μας είναι ανοιχτού κώδικα, επομένως είναι όλα δημόσια. Στη συνέχεια, αυτό που θα κάνουμε είναι προτού ο καθένας γράψει οποιεσδήποτε αλλαγές API ή είτε ένα νέο API ή αλλαγές σε ένα API, θα ενημερώσει πρώτα την τεκμηρίωση, θα έχει την αναθεώρηση αυτής της αλλαγής για να βεβαιωθεί ότι συμμορφώνεται με τις συμβάσεις και τα πρότυπα API που είναι όλα τεκμηριωμένα και βεβαιωθείτε ότι δεν υπάρχει καμία αλλαγή αλλαγής εδώ. Βεβαιωθείτε ότι συμμορφώνεται με τις συμβάσεις ονοματολογίας και ούτω καθεξής.

Εάν είστε πρόθυμοι να προχωρήσετε ένα βήμα παραπέρα, θα μπορούσατε να ασχοληθείτε με τη δοκιμή συμβολαίων API, η οποία - όπως αναφέρθηκε προηγουμένως - περιλαμβάνει δοκιμές γραφής και εκτέλεσης που διασφαλίζουν ότι η ρητή και σιωπηρή σύμβαση μιας μικροεπηρεσίας λειτουργεί όπως θα έπρεπε.

2. Η στρατηγική πλήρους στοίβας σε ένα κουτί

Η στρατηγική πλήρους στοίβας σε ένα κουτί συνεπάγεται την αναπαραγωγή ενός περιβάλλοντος cloud σε τοπικό επίπεδο και τον έλεγχο όλων σε μια εμφανή παρουσία ("$ vagrant up"). Το πρόβλημα? Είναι εξαιρετικά δύσκολο, όπως εξήγησε ο μηχανικός λογισμικού Cindy Sridharan του Imgix σε μια ανάρτηση ιστολογίου:

Είχα εμπειρία από πρώτο χέρι με αυτήν την πλάνη σε μια προηγούμενη εταιρεία στην οποία δούλευα όπου προσπαθήσαμε να περιστρέψουμε ολόκληρη τη στοίβα μας σε ένα [τοπικό] αληθινό κουτί. Η ιδέα, όπως θα φανταζόσασταν, ήταν ότι ένα απλό άρωμα θα έπρεπε να επιτρέπει σε κάθε μηχανικό της εταιρείας (ακόμη και frontend και mobile προγραμματιστές) να μπορεί να περιστρέφει τη στοίβα στο σύνολό της στους φορητούς υπολογιστές τους.

Ο Sridharan συνεχίζει λεπτομερώς πώς η εταιρεία είχε μόνο δύο μικροϋπηρεσίες, έναν διακομιστή API με βάση το gevent και μερικούς ασύγχρονους εργαζόμενους στο Python. Μια σχετικά απλή ρύθμιση, με κάθε τρόπο.

«Θυμάμαι ότι πέρασα ολόκληρη την πρώτη μου εβδομάδα σε αυτήν την εταιρεία προσπαθώντας να ανεβάζω με επιτυχία το VM τοπικά μόνο για να συναντήσω πληθώρα λαθών. Τελικά, περίπου στις 4:00 μ.μ. την Παρασκευή της πρώτης εβδομάδας μου, κατάφερα να λειτουργήσω με επιτυχία το Vagrant setup και να περάσω όλες τις δοκιμές σε τοπικό επίπεδο. Θυμάμαι ότι είμαι απίστευτα εξαντλημένος », διηγείται.

Επιπλέον, ο Stefan Zier, επικεφαλής αρχιτέκτονας της Sumo Logic, μου εξήγησε ότι - εκτός από το ότι είναι δύσκολο να το ξεπεράσεις - αυτή η τοπική στρατηγική δοκιμών απλά δεν κλιμακώνεται

«[Με] μια τοπική ανάπτυξη, εκτελούμε τις περισσότερες υπηρεσίες εκεί, ώστε να έχετε ένα πλήρως λειτουργικό σύστημα και αυτό τεντώνει τώρα ακόμη και τις μηχανές RAM 16 GB αρκετά σκληρά. Έτσι, αυτό δεν είναι πραγματικά κλίμακα », είπε.

3. Η στρατηγική δοκιμών AWS

Αυτή η τρίτη στρατηγική περιλαμβάνει τη δημιουργία υποδομής Amazon Web Services (AWS) για κάθε μηχανικό για την ανάπτυξη και εκτέλεση δοκιμών. Αυτή είναι μια πιο επεκτάσιμη προσέγγιση για τη στρατηγική πλήρους στοίβας σε κουτί που συζητήθηκε παραπάνω.

Ο Zier το ονόμασε «προσωπική ανάπτυξη [στρατηγική], όπου όλοι εδώ έχουν τον δικό τους λογαριασμό AWS».

«Μπορείτε να ανεβάσετε τον κωδικό που υπάρχει στον φορητό σας υπολογιστή σε AWS σε περίπου δέκα λεπτά και να τον εκτελέσετε σαν ένα πραγματικό σύστημα», είπε.

4. Η κοινή στρατηγική παρουσιών δοκιμών

Μου αρέσει να σκέφτομαι αυτήν την τέταρτη στρατηγική ως υβριδικό μεταξύ πλήρους stack in-a-box και δοκιμών AWS. Αυτό συμβαίνει επειδή περιλαμβάνει προγραμματιστές που εργάζονται από τον δικό τους, τοπικό σταθμό, αξιοποιώντας ταυτόχρονα μια ξεχωριστή, κοινόχρηστη παρουσία μιας μικροσυσκευής για να επισημάνει το τοπικό τους περιβάλλον κατά τη διάρκεια της δοκιμής.

Ο Steven Czerwinski, Επικεφαλής Μηχανικής, Scaylr, εξήγησε πώς μπορεί να λειτουργήσει στην πράξη:

Μερικοί από τους προγραμματιστές [μας] εκτελούν μια ξεχωριστή παρουσία μιας μικροσυσκευής για να χρησιμοποιηθούν για τον έλεγχο τοπικών εκδόσεων. Φανταστείτε λοιπόν ότι είστε προγραμματιστής, αναπτύσσεστε στον τοπικό σταθμό εργασίας σας και δεν έχετε εύκολο τρόπο εκκίνησης του προγράμματος ανάλυσης εικόνων. Ωστόσο, ο τοπικός σας δημιουργός θα έδειχνε απλώς έναν δοκιμαστικό αναλυτή εικόνας που εκτελείται στην υποδομή Google.

5. Η στρατηγική για τις ακινητοποιημένες υπηρεσίες

Και τέλος, διαθέτουμε τη στρατηγική δοκιμών για τις διαχωρισμένες υπηρεσίες.

Ο Zier παρουσίασε την προσέγγιση της SumoLogic για δοκιμασμένες υπηρεσίες, λέγοντάς μου πώς, «το stubbing ας γράψουμε αυτά τα σημάδια ή« stubs »μικροϋπηρεσιών που συμπεριφέρονται σαν να ήταν η σωστή υπηρεσία και διαφημίζονται στην ανακάλυψη υπηρεσιών μας σαν να ήταν πραγματική υπηρεσία , αλλά είναι απλώς μια ψεύτικη απομίμηση », εξήγησε.

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

Εργαλεία που θα σας βοηθήσουν να δοκιμάσετε τις μικροϋπηρεσίες

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

  • Hoverfly: προσομοίωση λανθάνουσας κατάστασης API και αστοχιών.
  • Vagrant: δημιουργία και συντήρηση φορητών εικονικών περιβαλλόντων ανάπτυξης λογισμικού
  • VCR: ένα εργαλείο δοκιμής μονάδας
  • Σύμφωνο: δοκιμές συμβολαίων με γνώμονα τους καταναλωτές.
  • Μελισσοκομείο: Εργαλείο τεκμηρίωσης API
  • API Blueprint: σχεδιασμός και πρωτότυπο API
  • Swagger: API σχεδιασμού και πρωτοτύπου

Δοκιμή μικροϋπηρεσιών: δύσκολο, αλλά αξίζει τον κόπο

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

Επιπλέον, οι στρατηγικές δοκιμών microservice που υιοθετήθηκαν από τους SumoLogic και Scaylr θα βοηθήσουν στην εξομάλυνση της διαδικασίας. Ακολουθεί μια γρήγορη ανακεφαλαίωση αυτών των στρατηγικών:

  1. Η πρώτη στρατηγική τεκμηρίωσης
  2. Η στρατηγική πλήρους στοίβας στο κουτί
  3. Η στρατηγική δοκιμών AWS
  4. Η κοινή στρατηγική παρουσιών δοκιμών
  5. Η στρατηγική για τις ακινητοποιημένες υπηρεσίες

Φυσικά, μπορεί να χρειαστεί να τροποποιήσετε κάθε στρατηγική ώστε να ταιριάζει με τις μοναδικές σας περιστάσεις, αλλά με κάποιες παλιομοδίτικες δοκιμές και λάθη, η στρατηγική δοκιμών μικροϋπηρεσίας θα πρέπει να έρθει στη δική της.

Αν σας άρεσε αυτό το άρθρο, βοηθήστε το να εξαπλωθεί πατώντας παρακάτω! Για περισσότερο περιεχόμενο όπως αυτό, ακολουθήστε μας στο Twitter και εγγραφείτε στο ιστολόγιό μας.

Ο Jake Lumetta είναι διευθύνων σύμβουλος της ButterCMS και δημοσιεύει Microservices for Startups.

Και αν θέλετε να προσθέσετε ένα blog ή CMS στον ιστότοπό σας χωρίς να χτυπήσετε το Wordpress, θα πρέπει να δοκιμάσετε το Butter CMS.