Jumătatea plictisitoare a livrării de software

Cam jumătate din ce facem nu se vede într-un demo. E partea care decide dacă jumătatea vizibilă mai stă în picioare peste un an, așa că merită descrisă pe șleau.

Un deploy pe care îl poți da înapoi valorează mai mult decât unul care merge

Oricine livrează într-o zi bună. Întrebarea e cum arată joi la 17:40, când ziua bună se termină. Ținem fiecare release reversibil dintr-un singur pas — sună evident și, discret, elimină o listă lungă de scurtături comode: migrări ireversibile, schimbări de schemă încâlcite în codul de funcționalitate, configurări care trăiesc doar în capul cuiva.

Migrările rulează de două ori, intenționat

O migrare care nu poate rula de două ori fără să strice e o migrare care nu poate fi reîncercată, iar ce nu poate fi reîncercat va pica într-o zi la jumătate. Scrisă ca să fie repetabilă, costă o oră și îți scoate din calendar o categorie întreagă de seri proaste.

Lista nespectaculoasă

• Fiecare variabilă de mediu de care are nevoie un build e declarată și verificată, nu descoperită în timpul rulării.
• Baza de date de staging se restaurează periodic din producție, ca să știm că restaurarea chiar funcționează.
• Rapoartele de eroare poartă cererea și utilizatorul, pentru că un stack trace singur rar găsește bug-ul.
• Bugetele de performanță pică build-ul, nu un dashboard pe care nu îl deschide nimeni.

De ce ajunge asta în preț

Ni se cere uneori să sărim peste jumătatea asta ca să mergem mai repede, iar pentru un prototip făcut să fie aruncat e decizia corectă. Pentru orice depinde o firmă, e diferența dintre un software care e activ și unul care devine pasiv în ziua în care pleacă autorul lui.

Am scris despre unde se decid lucrurile astea — înainte să se scrie cod — în materialul despre discovery.

Faza de discovery software