{"id":229899,"date":"2022-11-07T13:30:00","date_gmt":"2022-11-07T10:30:00","guid":{"rendered":"https:\/\/wordpress.mediadoma.com\/?p=229899"},"modified":"2022-11-09T19:12:23","modified_gmt":"2022-11-09T16:12:23","slug":"project-guardrails-scrittura-per-la-produzione","status":"publish","type":"post","link":"https:\/\/wordpress.mediadoma.com\/it\/project-guardrails-scrittura-per-la-produzione\/","title":{"rendered":"Project Guardrails: scrittura per la produzione"},"content":{"rendered":"\n

Negli ultimi articoli, ho parlato di un paio di cose (salvate per scrivere effettivamente alla produzione) che aiutano a gestire un progetto di successo:<\/p>\n

    \n
  1. I pericoli del " design by comitato<\/a> "<\/li>\n
  2. Considerazioni per il provisioning di un ambiente<\/a>.<\/li>\n<\/ol>\n

    L’ultima cosa di cui voglio parlare con l’apprendimento che ho sperimentato finora riguarda il mantenimento delle proverbiali chiavi del regno della scrittura e della produzione e il motivo per cui \u00e8 importante.<\/p>\n

    Scrivere alla produzione<\/h2>\n

    L’idea di scrivere per la produzione pu\u00f2 sembrare il guardrail pi\u00f9 dogmatico di quelli menzionati perch\u00e9 di solito va bene per coloro che stanno costruendo la soluzione e conoscono i dettagli di come sta funzionando.<\/p>\n

    Probabilmente le altre parti interessate non lo fanno (ma se lo fanno e il team di sviluppo \u00e8 d’accordo con gli altri che usano il controllo della versione per gestirlo, allora provaci).<\/p>\n

    Chi ha il permesso di amministrare questa roba, davvero?<\/p>\n

    Ricorda, tuttavia, come accennato in precedenza in questa serie<\/a>, il modo in cui stiamo implementando i nostri progetti \u00e8 cambiato ora in modo tale che spesso abbiamo un’implementazione continua e un’integrazione continua.<\/p>\n

    E spesso, questi servizi sono collegati a un repository di codice sorgente, come GitHub<\/a>, e un sistema di messaggistica (che, a sua volta, pu\u00f2 essere collegato a Slack<\/a> che trovo utile).<\/p>\n

    In modo che le persone del team siano a conoscenza di cosa \u00e8 stato distribuito e quando e sappiano come ottenere il codice (che \u00e8 dal repository, non dal download tramite S\/FTP), se necessario.<\/p>\n

    Quando \u00e8 necessario un aggiornamento rapido, dovrebbe esserci ancora una procedura in atto. Forse qualcuno \u00e8 di guardia ed esiste un processo mediante il quale vengono utilizzati branching, merge, tagging e versioning semantico<\/a>.<\/p>\n

    Indipendentemente da ci\u00f2, non si tratta tanto di come funziona il processo; \u00e8 che \u00e8 a posto e che \u00e8 seguito.<\/p>\n

    Naturalmente, queste cose non sono messe in atto per rendere lo sviluppo pi\u00f9 complicato (anche se capisco come possa sembrare cos\u00ec). \u00c8 il contrario. \u00c8 per una serie di motivi:<\/p>\n