Devios CMS

Κατηγορία: Οργάνωση υποδομής

Projects, πόροι, τεκμηρίωση και runbooks: όλη η υποδομή της ομάδας σε τάξη.

  • Γνωρίστε το Devios: το κέντρο ελέγχου που φτιάξαμε για τη δική μας υποδομή

    Γνωρίστε το Devios: το κέντρο ελέγχου που φτιάξαμε για τη δική μας υποδομή

    Στην 7Studios φτιάχνουμε και τρέχουμε sites, e-shops και εφαρμογές για πελάτες. Κάπου ανάμεσα στο δέκατο project και στον τρίτο server, η ερώτηση «πού τρέχει αυτό;» άρχισε να θέλει δέκα λεπτά για να απαντηθεί. Η ερώτηση «πόσο μας κοστίζει αυτός ο πελάτης;» δεν απαντιόταν καθόλου. Έτσι φτιάξαμε το Devios.

    Το πρόβλημα που λύνει

    Μια εταιρεία πληροφορικής δεν έχει έλλειψη εργαλείων. Έχει πάρα πολλά: πίνακες από Hostinger, Cloudflare, GitHub, Supabase, ένα password manager, ένα εργαλείο uptime, ένα Excel με λήξεις, και το λογιστικό. Κανένα δεν ξέρει για τα άλλα, και κανένα δεν ξέρει για τους πελάτες.

    Το Devios τα δένει γύρω από αυτό που πραγματικά διαχειρίζεσαι: πελάτες και projects.

    Τι κάνει σήμερα

    • Projects και πόροι. Πελάτες, projects, περιβάλλοντα και 28 τύποι πόρων, με χάρτη ανά project και κόστος που μοιράζεται.
    • Θησαυροφυλάκιο. Zero-knowledge κρυπτογράφηση στον browser, μία συλλογή ανά project, ιστορικό σε κάθε προβολή, σύνδεσμος μίας χρήσης για πελάτες.
    • Φύλακας. Έλεγχοι HTTP και TCP έως κάθε λεπτό, SSL, περιστατικά, δημόσια σελίδα κατάστασης.
    • Λήξεις και ειδοποιήσεις. Domains, πιστοποιητικά, συνδρομές, με ειδοποίηση σε Email, Telegram και Push.
    • Συνδέσεις. Hostinger, GitHub, Supabase, Resend και Anthropic φέρνουν μόνοι τους ό,τι έχεις.
    • Κόστη. Κόστος, χρέωση και περιθώριο ανά πελάτη, σε ευρώ με ισοτιμίες ΕΚΤ.
    • Βαθμός ασφάλειας 0 έως 100 και μηνιαία αναφορά ανά πελάτη.
    • Βοηθός με Claude που απαντά σε ερωτήσεις για την υποδομή, χωρίς να βλέπει ποτέ κωδικούς.

    Τρεις αρχές που κρατήσαμε

    Ούτε εμείς δεν βλέπουμε τους κωδικούς

    Οι κωδικοί των πελατών είναι το πιο ευαίσθητο πράγμα μιας agency. Γι’ αυτό κρυπτογραφούνται στη συσκευή σου με κλειδί από το master password σου, και ο server αποθηκεύει μόνο κρυπτογραφήματα. Αναλυτικά στο τι σημαίνει zero-knowledge.

    Μόνο αναγνώσεις στους παρόχους

    Οι συνδέσεις διαβάζουν, δεν αλλάζουν τίποτα. Ένα εργαλείο καταγραφής δεν πρέπει να μπορεί να σβήσει έναν server.

    Στα ελληνικά, από την αρχή

    Όχι μετάφραση από τα αγγλικά. Φυσικοί όροι, ελληνικές ημερομηνίες και ποσά, ευρώ.

    Πού πηγαίνει

    Το Devios ξεκίνησε ως εσωτερικό εργαλείο και το χρησιμοποιούμε κάθε μέρα. Τώρα ανοίγει σταδιακά σε άλλες agencies και ομάδες IT. Στη λίστα για τους επόμενους μήνες είναι περισσότεροι πάροχοι (Cloudflare, Stripe, DigitalOcean), μετρήσεις servers και αγγλικό περιβάλλον.

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

    Συχνές ερωτήσεις

    Για ποιον είναι το Devios;

    Για agencies, freelancers με πολλούς πελάτες και εσωτερικές ομάδες IT που τρέχουν sites, εφαρμογές και servers και θέλουν μία εικόνα για όλα.

    Χρειάζεται εγκατάσταση;

    Όχι. Δουλεύει από τον browser και εγκαθίσταται στο κινητό σαν εφαρμογή (PWA), με ειδοποιήσεις Push.

    Μπορούν να μπουν οι πελάτες μου;

    Ναι, με ρόλο «Πελάτης»: βλέπουν μόνο τα δικά τους projects, αν λειτουργούν, το uptime και τις ανανεώσεις, χωρίς κόστη και κωδικούς.

  • Από το Excel στο κέντρο ελέγχου: η πρώτη καταγραφή projects και πόρων σε μία μέρα

    Από το Excel στο κέντρο ελέγχου: η πρώτη καταγραφή projects και πόρων σε μία μέρα

    Η μετάβαση από ένα Excel σε ένα κανονικό εργαλείο μοιάζει με έργο εβδομάδων. Δεν είναι, αν την κάνεις με τη σωστή σειρά. Εδώ είναι ένα σχέδιο μίας εργάσιμης, όπως το δουλεύουμε με ομάδες που ξεκινούν.

    Πριν ξεκινήσεις: τι μαζεύεις

    Δεν χρειάζεται τέλειο υλικό. Χρειάζεσαι:

    • Τη λίστα πελατών (ακόμα και από το λογιστικό).
    • Πρόσβαση στους λογαριασμούς των βασικών παρόχων: hosting, domains, GitHub, βάσεις.
    • Το Excel ή τα Excel που υπάρχουν, όσο παλιά κι αν είναι.
    • Το export του password manager, αν υπάρχει.

    Πρωί: συνδέσεις παρόχων (1 ώρα)

    Ξεκίνα από αυτό που γεμίζει μόνο του. Για κάθε πάροχο φτιάξε ένα token μόνο ανάγνωσης και σύνδεσέ το. Μέσα σε λίγα λεπτά έρχονται domains με λήξεις, servers με IP και πακέτα, sites, repositories και βάσεις.

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

    Πριν το μεσημέρι: πελάτες και projects (1,5 ώρα)

    Φτιάξε τους πελάτες και μόνο τα live projects. Για κάθε project, τρία πράγματα αρκούν τώρα: όνομα, τύπος (site, e-shop, εφαρμογή, API) και διεύθυνση. Τα αρχειοθετημένα και τα ημιτελή περιμένουν για την επόμενη εβδομάδα.

    Αν έχεις μηνιαία χρέωση ανά πελάτη, γράψ’ την τώρα. Θα τη χρειαστείς για το περιθώριο.

    Μεσημέρι: πόροι στα projects (2 ώρες)

    Αυτό είναι το κύριο κομμάτι. Πάρε τη λίστα με ό,τι έφεραν οι πάροχοι και βάλε κάθε πόρο στο project του. Ό,τι έχει ίδιο domain ή όνομα με κάποιο project ταιριάζει αυτόματα· τα υπόλοιπα τα βάζεις με ένα κλικ.

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

    Μετά πέρνα τα μόνο από το Excel: πόρους που δεν βλέπει κανένας πάροχος, όπως άδειες plugins, λογαριασμούς Apple Developer ή ένα domain στο Papaki του πελάτη.

    Απόγευμα: κωδικοί (1 ώρα)

    Κάνε εισαγωγή από τον password manager (Bitwarden, 1Password, LastPass, Chrome ή Firefox) και μοίρασε τους κωδικούς στις συλλογές των projects. Ό,τι ήταν σε Excel, πέρασέ το με το χέρι και σβήσε το αρχείο. Δες γιατί στον οδηγό διαχείρισης κωδικών.

    Τέλος της μέρας: έλεγχοι και ειδοποιήσεις (30 λεπτά)

    1. Βάλε έναν έλεγχο λειτουργίας σε κάθε live site.
    2. Σύνδεσε ένα κανάλι ειδοποιήσεων: Email για όλους, Telegram ή Push για τον υπεύθυνο βάρδιας.
    3. Άνοιξε τις λήξεις των επόμενων 60 ημερών. Σχεδόν πάντα κάτι βρίσκεται.
    4. Δες τους πόρους χωρίς project: συνδρομές που πληρώνεις χωρίς λόγο.

    Η επόμενη εβδομάδα

    • Runbooks για τα τρία πιο κρίσιμα projects.
    • Πρόσβαση στους developers ανά project.
    • Τα αρχειοθετημένα projects, για να κλείσουν οι πόροι που περισσεύουν.
    • Η πρώτη μηνιαία αναφορά κόστους.

    Συχνές ερωτήσεις

    Τι κάνω με τα στοιχεία του Excel που δεν ξέρω αν ισχύουν;

    Μην τα περάσεις τυφλά. Αν ένας πόρος δεν εμφανίζεται σε κανέναν πάροχο και κανείς δεν ξέρει τι είναι, γράψ’ τον με σημείωση «να ελεγχθεί» και κοίτα τον την επόμενη εβδομάδα.

    Πρέπει να σταματήσει η δουλειά για να γίνει η μετάβαση;

    Όχι. Ένας άνθρωπος αρκεί για την πρώτη μέρα. Η υπόλοιπη ομάδα μπαίνει όταν τα projects της είναι έτοιμα.

    Τι γίνεται με τους λογαριασμούς που είναι στο όνομα πρώην συνεργάτη;

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

  • Runbooks: τι πρέπει να γράφει κάθε project για να μη χαθεί η γνώση

    Runbooks: τι πρέπει να γράφει κάθε project για να μη χαθεί η γνώση

    Κάθε ομάδα έχει έναν άνθρωπο που «ξέρει πώς γίνεται το deploy στο eshop». Μέχρι να πάει διακοπές. Το runbook είναι ο τρόπος να βγει αυτή η γνώση από το κεφάλι του και να μπει δίπλα στο project, εκεί που θα τη χρειαστεί ο επόμενος.

    Τι είναι (και τι δεν είναι) ένα runbook

    Ένα runbook είναι οδηγίες για ενέργειες: πώς κάνεις κάτι συγκεκριμένο, βήμα βήμα. Δεν είναι τεκμηρίωση αρχιτεκτονικής, δεν είναι README για developers, δεν είναι ιστορικό αποφάσεων. Αν η σελίδα δεν απαντά στο «τι πατάω τώρα;», δεν είναι runbook.

    Το καλό runbook διαβάζεται από κάποιον που ξέρει τη δουλειά αλλά δεν ξέρει το project. Αυτό είναι το μέτρο.

    Τα πέντε runbooks που χρειάζεται κάθε project

    1. Deploy. Από πού, με ποια εντολή, πώς ελέγχεις ότι πέτυχε.
    2. Rollback. Πώς γυρνάς στην προηγούμενη έκδοση, και τι γίνεται με τη βάση αν άλλαξε.
    3. Backups και επαναφορά. Πού είναι, πόσο συχνά, πόσο κρατιούνται, και πότε δοκιμάστηκε τελευταία φορά η επαναφορά.
    4. Το site έπεσε. Τι ελέγχεις με τη σειρά: DNS, πιστοποιητικό, server, εφαρμογή, βάση.
    5. Ανανεώσεις. Ποιος πληρώνει το domain, πού γίνεται η ανανέωση, τι θέλει χειροκίνητη κίνηση.

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

    Ένα πρότυπο που μπορείς να αντιγράψεις

    ## Deploy
1. Merge στο main.
2. Ο server τραβά και κάνει build μόνος του (~2 λεπτά).
3. Έλεγχος: https://example.gr/api/health επιστρέφει "ok".

## Rollback
1. git revert του τελευταίου merge και νέο deploy.
2. Αν άλλαξε η βάση: επαναφορά από το backup της νύχτας
   (βλ. «Backups»). Ρώτα πρώτα τον υπεύθυνο του project.

## Backups
- Καθημερινά 03:00, 30 ημέρες, στο bucket backups-prod.
- Τελευταία δοκιμή επαναφοράς: 12/9/2026.

## Πού είναι τι
- Hosting: VPS παραγωγής (βλ. πόροι του project)
- DNS: Cloudflare του πελάτη, όχι δικό μας
- Κωδικοί: συλλογή του project στο θησαυροφυλάκιο
    Ποτέ κωδικοί μέσα στο runbookΤο runbook λέει «ο κωδικός είναι στη συλλογή του project». Ο ίδιος ο κωδικός μένει στο θησαυροφυλάκιο, όπου κάθε προβολή καταγράφεται.

    Πού να ζει το runbook

    Η απάντηση είναι απλή: δίπλα στους πόρους του project. Όχι σε ένα ξεχωριστό wiki, όχι σε ένα Google Doc με σύνδεσμο που χάνεται. Όταν ανοίγεις το project για να δεις σε ποιον server τρέχει, το runbook πρέπει να είναι μία καρτέλα δίπλα.

    Το Markdown είναι η σωστή μορφή: γράφεται γρήγορα, διαβάζεται παντού, και τα βήματα με αριθμούς και τα κομμάτια κώδικα φαίνονται καθαρά.

    Πώς μένει ενημερωμένο

    Ένα παλιό runbook είναι χειρότερο από κανένα, γιατί σε κάνει να εμπιστεύεσαι κάτι λάθος. Τρεις συνήθειες βοηθούν:

    • Ενημέρωση μετά από κάθε περιστατικό. Αν κάτι δεν ήταν γραμμένο, γράφεται στο post-mortem και μετά στο runbook.
    • Ημερομηνία και όνομα. Φαίνεται ποιος άλλαξε τι και πότε. Ένα runbook που δεν έχει αγγιχτεί δύο χρόνια θέλει έλεγχο.
    • Δοκιμή από άλλον. Μία φορά τον χρόνο, κάποιος που δεν ξέρει το project κάνει deploy μόνο με το runbook. Ό,τι κόλλησε, διορθώνεται.

    Τα συνηθισμένα λάθη

    • Πολύ μεγάλο: κανείς δεν διαβάζει δέκα σελίδες υπό πίεση.
    • Γενικές οδηγίες («κάνε restart στην υπηρεσία») χωρίς την ακριβή εντολή.
    • Υποθέσεις που ξέρει μόνο ο συγγραφέας («από τον γνωστό λογαριασμό»).
    • Κανένα βήμα επιβεβαίωσης: πώς ξέρω ότι το deploy πέτυχε;

    Συχνές ερωτήσεις

    Πόσο μεγάλο πρέπει να είναι ένα runbook;

    Όσο χρειάζεται για να γίνει η ενέργεια χωρίς να ρωτήσεις κάποιον. Συνήθως μία οθόνη ανά ενέργεια. Αν μεγαλώνει, χώρισέ το.

    Ποιος γράφει τα runbooks;

    Αυτός που στήνει το project γράφει την πρώτη εκδοχή. Μετά, όποιος βρίσκει κάτι λάθος ή κάτι που λείπει το διορθώνει εκείνη τη στιγμή.

    Αξίζει runbook για ένα μικρό WordPress site;

    Ναι, ένα σύντομο: πού φιλοξενείται, πού είναι το DNS, πού τα backups, ποιος πληρώνει το domain. Πέντε γραμμές σε γλιτώνουν από μία ώρα ψαξίματος.

  • Πώς οργανώνεις όλη την υποδομή μιας εταιρείας πληροφορικής σε ένα μέρος

    Πώς οργανώνεις όλη την υποδομή μιας εταιρείας πληροφορικής σε ένα μέρος

    Κάθε εταιρεία πληροφορικής ξεκινά με τρία sites και ένα Excel. Δύο χρόνια μετά έχει σαράντα πελάτες, τρεις servers, δύο λογαριασμούς Hostinger, έναν στο Cloudflare που άνοιξε κάποιος που έφυγε, και ένα Excel που κανείς δεν εμπιστεύεται. Το πρόβλημα δεν είναι η έλλειψη εργαλείων. Είναι ότι η γνώση για το τι τρέχει πού ζει σκορπισμένη σε πίνακες παρόχων, inbox και κεφάλια.

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

    Γιατί το Excel σταματά να δουλεύει

    Ένα spreadsheet είναι εξαιρετικό για να ξεκινήσεις και κακό για να συνεχίσεις. Τρία πράγματα το σπάνε:

    • Οι σχέσεις. Ένας VPS εξυπηρετεί πέντε projects, ένα domain έχει DNS σε άλλον πάροχο, ένα κλειδί Anthropic χρεώνεται σε δύο πελάτες. Οι γραμμές ενός πίνακα δεν δείχνουν σχέσεις πολλά-προς-πολλά.
    • Η φρεσκάδα. Οι λήξεις, οι τιμές και οι IP αλλάζουν στους παρόχους. Ό,τι γράφτηκε με το χέρι είναι ήδη παλιό.
    • Οι κωδικοί. Μόλις μπει ένας κωδικός στο ίδιο αρχείο, το αρχείο γίνεται το πιο επικίνδυνο πράγμα της εταιρείας.

    Το μοντέλο: πελάτες, projects, πόροι

    Η δομή που δουλεύει στην πράξη έχει τρία επίπεδα:

    1. Πελάτης. Η εταιρεία που πληρώνει. Μπορεί να έχει πολλά projects. Τα εσωτερικά projects (το site σας, τα εργαλεία σας) δεν έχουν πελάτη.
    2. Project. Κάτι που παραδίδετε και συντηρείτε: ένα e-shop, μια εφαρμογή, ένα API. Έχει κατάσταση (σε ανάπτυξη, live, συντήρηση) και προαιρετικά περιβάλλοντα, όπως production και staging.
    3. Πόρος. Οτιδήποτε χρειάζεται το project για να ζει: domain, DNS, πιστοποιητικό SSL, server, hosting, βάση, repository, email, AI provider, πληρωμές, άδειες.

    Το κλειδί είναι ότι ο πόρος δεν ανήκει σε ένα μόνο project. Ο server παραγωγής συνδέεται με όλα τα projects που φιλοξενεί, και το κόστος του μοιράζεται με ποσοστό. Έτσι απαντάς αμέσως σε δύο ερωτήσεις που αλλιώς θέλουν ώρες: «τι πέφτει αν πέσει αυτός ο server;» και «πόσο μας κοστίζει αυτός ο πελάτης;».

    Τι πρέπει να ξέρεις για κάθε πόρο

    Δεν χρειάζεσαι εκατό πεδία. Χρειάζεσαι αυτά που απαντούν στις ερωτήσεις μιας κακής μέρας:

    Πεδίο Γιατί το θέλεις
    Πάροχος και λογαριασμός Για να ξέρεις σε ποιο login να μπεις όταν κάτι χαλάσει.
    Βασικό αναγνωριστικό Domain, IP, όνομα repo ή βάσης. Αυτό που ψάχνεις.
    Λήξη και αυτόματη ανανέωση Τα περισσότερα «έπεσε το site» είναι στην πραγματικότητα «έληξε κάτι».
    Κόστος και κύκλος χρέωσης Μηνιαίο, ετήσιο, εφάπαξ, δωρεάν, και σε ποιο νόμισμα.
    Σημειώσεις Ό,τι δεν χωρά αλλού: «το DNS είναι στο Cloudflare του πελάτη».
    Κανόνας χρυσόςΟι κωδικοί δεν μπαίνουν ποτέ στα πεδία ενός πόρου. Μπαίνουν σε θησαυροφυλάκιο, δεμένοι με τον πόρο. Ένα καλό εργαλείο απορρίπτει πεδία που μοιάζουν με κωδικό.

    Οι κωδικοί, χωριστά αλλά δίπλα

    Το θησαυροφυλάκιο κωδικών πρέπει να ακολουθεί την ίδια δομή: μία συλλογή ανά project. Όταν ένας developer παίρνει πρόσβαση σε ένα project, βλέπει τους πόρους και τους κωδικούς του, και τίποτα άλλο. Όταν φεύγει, ξέρεις ακριβώς ποιους κωδικούς είδε και πρέπει να αλλάξουν. Περισσότερα στον οδηγό διαχείρισης κωδικών.

    Ποιος βλέπει τι

    Ένα σχήμα ρόλων που καλύπτει σχεδόν κάθε agency:

    • Ιδιοκτήτης και Διαχειριστής: όλα, μαζί με κόστη και ομάδα.
    • Developer: μόνο τα projects που του έχουν δοθεί, και προσωρινά αν χρειάζεται.
    • Μόνο προβολή: για συνεργάτες που χρειάζονται εικόνα χωρίς κωδικούς.
    • Πελάτης: τα δικά του projects, αν λειτουργούν και τι ανανεώνεται, χωρίς κόστη και εσωτερικές σημειώσεις.

    Δύο λεπτομέρειες κάνουν τη διαφορά: κανείς δεν μπορεί να δώσει ρόλο ψηλότερο από τον δικό του, και κάθε ενέργεια γράφεται σε ιστορικό που δεν σβήνει.

    Πώς μένει ενημερωμένο χωρίς κόπο

    Η καταγραφή πεθαίνει τη μέρα που γίνεται αγγαρεία. Τρεις μηχανισμοί την κρατούν ζωντανή:

    1. Συνδέσεις με τους παρόχους. Με ένα token μόνο ανάγνωσης, ο πάροχος φέρνει μόνος του domains, servers, repos, βάσεις, λήξεις και τιμές. Ό,τι βρεθεί ταιριάζει με τους πόρους που υπάρχουν ήδη, με βάση το domain, την IP ή το όνομα.
    2. Παρακολούθηση. Έλεγχοι λειτουργίας και SSL επιβεβαιώνουν κάθε λεπτό ότι αυτό που γράφει η καταγραφή είναι αλήθεια.
    3. Ειδοποιήσεις για λήξεις. Όταν η καταγραφή σε προστατεύει από ένα ξεχασμένο domain, η ομάδα σταματά να τη βλέπει σαν γραφειοκρατία.

    Το πρώτο απόγευμα: ένα σχέδιο

    Μην προσπαθήσεις να καταγράψεις τα πάντα την πρώτη μέρα. Ξεκίνα έτσι:

    1. Σύνδεσε τους βασικούς παρόχους (hosting, GitHub, βάσεις).
    2. Φτιάξε τους πελάτες και τα live projects. Τα παλιά και αρχειοθετημένα περιμένουν.
    3. Βάλε τους πόρους που έφεραν οι πάροχοι στα projects τους.
    4. Πρόσθεσε έναν έλεγχο λειτουργίας σε κάθε live site.
    5. Κοίτα τη λίστα «πόροι χωρίς project». Εκεί κρύβονται συνδρομές που πληρώνεις χωρίς λόγο.

    Αναλυτικά βήματα θα βρεις στο από το Excel στο κέντρο ελέγχου σε μία μέρα.

    Τεκμηρίωση που διαβάζεται

    Η καταγραφή λέει τι υπάρχει. Τα runbooks λένε πώς δουλεύει: πώς γίνεται deploy, πώς γυρνάς πίσω, πού είναι τα backups. Ένα σύντομο runbook ανά project, δίπλα στους πόρους του, αξίζει περισσότερο από ένα wiki που κανείς δεν ανοίγει. Δες τι πρέπει να γράφει κάθε runbook.

    Συχνές ερωτήσεις

    Πόσο χρόνο θέλει η πρώτη καταγραφή;

    Για μια ομάδα με 20 έως 40 projects, ένα απόγευμα αν συνδέσεις τους παρόχους. Το μεγαλύτερο κομμάτι είναι να αποφασίσεις σε ποιο project ανήκει κάθε πόρος, όχι η πληκτρολόγηση.

    Πρέπει να καταγράψω και τα δωρεάν εργαλεία;

    Ναι, αν το project εξαρτάται από αυτά. Ένα δωρεάν πλάνο που ξεπερνά το όριό του ή ένας λογαριασμός που ανήκει σε πρώην συνεργάτη είναι κίνδυνος, ακόμα κι αν δεν κοστίζει.

    Τι κάνω με πόρους που μοιράζονται πολλοί πελάτες;

    Τους συνδέεις με όλα τα projects και ορίζεις ποσοστό κόστους για το καθένα. Έτσι το περιθώριο ανά πελάτη βγαίνει σωστό, και ξέρεις ποιοι επηρεάζονται αν πέσει ο πόρος.

    Χρειάζομαι περιβάλλοντα (production, staging);

    Μόνο όπου υπάρχουν πραγματικά. Για ένα απλό site είναι περιττά· για μια εφαρμογή με staging και production βοηθούν να μην μπερδευτούν οι βάσεις και τα κλειδιά.