Projekt Guardrails: pisanie do produkcji
W ostatnich kilku artykułach mówiłem o kilku rzeczach (zapisanych do faktycznego pisania do produkcji), które pomagają w prowadzeniu udanego projektu:
- Zagrożenia w „ projektowaniu przez komisję ",
- Uwagi dotyczące udostępniania środowiska.
Ostatnią rzeczą, jaką chciałbym odnieść się do nauki, której do tej pory doświadczyłem, jest utrzymanie przysłowiowych kluczy do królestwa pisania do produkcji i dlaczego to ma znaczenie.
Pisanie do produkcji
Pomysł pisania do produkcji może wydawać się najbardziej dogmatyczną barierą ochronną z wymienionych, ponieważ zwykle jest w porządku dla tych, którzy budują rozwiązanie i znają tajniki jego działania.
Inni interesariusze prawdopodobnie tego nie robią (ale jeśli tak, a zespół programistów nie ma nic przeciwko innym, którzy używają kontroli wersji do obsługi tego, to zrób to).
Kto naprawdę ma pozwolenie na administrowanie tymi rzeczami?
Pamiętaj jednak, jak wspomniano wcześniej w tej serii, sposób, w jaki wdrażamy nasze projekty, zmienił się teraz tak, że często mamy do czynienia z ciągłym wdrażaniem i ciągłą integracją.
I często te usługi są podłączone do repozytorium kodu źródłowego, takiego jak GitHub, i systemu przesyłania wiadomości (który z kolei może być podłączony do Slacka, co uważam za przydatne).
Aby ludzie w zespole byli świadomi tego, co zostało wdrożone i kiedy, i wiedzieli, jak w razie potrzeby uzyskać kod (który pochodzi z repozytorium, a nie z pobierania go przez S/FTP).
Gdy potrzebna jest poprawka, nadal powinna istnieć procedura. Być może ktoś jest na zawołanie i istnieje proces, w którym używane jest rozgałęzianie, łączenie, tagowanie i wersjonowanie semantyczne.
Niezależnie od tego, nie chodzi tak bardzo o to, jak działa ten proces; chodzi o to, że jest na swoim miejscu i jest przestrzegany.
Oczywiście te rzeczy nie są wprowadzane w celu komplikowania rozwoju (chociaż rozumiem, jak to może wyglądać w ten sposób). Wręcz przeciwnie. Dzieje się tak z różnych powodów:
- aby utrzymać ciągłe wdrażanie, wiesz, ciągłe,
- mieć zintegrowane testy,
- do ciągłego pomiaru standardów kodowania lub jakości kodu,
- aby zapobiec kodowaniu kowbojskiemu,
- i więcej.
Nie chodzi tu o trzymanie innych ludzi z daleka, ale jeśli to programiści są odpowiedzialni za wypychanie kodu, to czy ktokolwiek inny naprawdę powinien mieć dostęp do zapisu na serwerze?
I to jest sedno: jeśli pracujesz w zespole, w którym procesy, które masz, mogą całkowicie podważyć twoją pracę, to jaki jest cel tego procesu?
Ponieważ w każdej chwili może pojawić się ktoś inny, a to zignoruje wszystko, co zrobiłeś. Jesteś więc przynajmniej:
- utknąłem z koniecznością ściągania swoich zmian prawdopodobnie przez S/FTP,
- porównaj go za pomocą narzędzia diff z gałęzią, na której ktoś pracuje,
- wdrożyć zmiany (pozwól nam dowiedzieć się, dlaczego zostały wprowadzone),
- a następnie wróć do pracy nad wymaganiami.
Brzmi to gorączkowo, kiedy tak to ujmujesz, ale tak właśnie się dzieje.
Na wynos
Więc jaki jest cel ostatnich kilku postów? Gdybym miał to podsumować tak zwięźle, jak to możliwe, to:
Jeśli chodzi o projekt, poznaj swoje obowiązki i nie wychodź z nich. W przeciwnym razie ryzykujesz wykolejenie całej rzeczy.
Dotyczy to programistów, projektantów, klientów, marketerów, kierowników projektów itp. Jak wyznaczane są role, nie ma większego znaczenia (to znaczy, zwykle jest jasne, kto powinien być kim w powyższych rolach), ale mam na myśli kim jest rzeczywista osoba punktowa – właściciel projektu – dla całego projektu.
Nie bądź taki.
I w zależności od tego, jak wszystko się zgadza, projekt może być stosunkowo prostym zestawem codziennej pracy.
O ile to możliwe, czy nie chcemy cieszyć się tym, co robimy