Poręcze projektu: środowiska aprowizacji

Ta seria krótkich artykułów składa się z kilku rzeczy, których nauczyłem się w ciągu ostatnich kilku lat prowadzenia projektów w obszarze, w którym my (zakładając, że czytasz to z tej samej branży, co ja 🙂) praca.

Jeśli po prostu natkniesz się na to, seria obejmuje kilka czynników, które są ważne dla projektu :

1. Nie powinno być „ projektu przez komisję. “
2. Nikt inny niż główny zespół programistów powinien być w stanie zapewnić rozwój, etapowanie i produkcję.
3. Nikt nie powinien być w stanie pisać do produkcji, ale zespół programistów (a nawet wtedy powinien nastąpić proces wdrożenia).

Naprawdę nie lubię tworzyć twardych i szybkich zasad, takich jak ta, ponieważ rzeczy zmieniają się w czasie albo z konieczności, albo z większego doświadczenia. Dlatego lubię „wytyczne".

Ale w chwili pisania tego tekstu są to rzeczy, które widzę.

Środowiska aprowizacji

W ciągu ostatnich kilku lat poczyniliśmy znaczne postępy w zakresie szybkości udostępniania naszych systemów, tak aby wszystkie odzwierciedlały się nawzajem (lub ogólnie). Obejmuje to nasze skrzynki programistyczne, sposób, w jaki nasze lokalne maszyny odzwierciedlają pomostowanie oraz jak pomostowanie odzwierciedla produkcję.

Zapewnienie nowego środowiska, mniej więcej. Rzuć się z tym.

To znaczy, jeśli „działa na moim komputerze” powinno być prawdą. Nie jest to wymówka dla niemożności odtworzenia błędu.

A kiedy to prawda, prawdopodobnie będzie to dotyczyć maszyn innych, inscenizacji i produkcji. I to jest miłe, prawda? To znaczy, rozkręcamy nasze pudełka, wdrażamy nasze skrypty lub robimy to, co robimy, a potem mamy konfigurację, której potrzebujemy.

Więc co to znaczy korzystać ze środowisk aprowizacji? Zależy to od środowiska, do którego się odnosisz.

Jak to naprawdę wygląda?

Jeśli pracujesz w WordPressie, a zakładam, że tak jest, jeśli to czytasz, to zakłada, że ​​używasz przynajmniej serwera WWW, bazy danych i PHP.

Środowisko programistyczne może wyglądać następująco:

• Apache Nginx, _
• MySQL, który jest najczęstszy,
• Przynajmniej PHP 5.2.4 (zalecane PHP 7.1),
• Albo coś porównywalnego.

Możesz również używać czegoś takiego jak Laravel Valet lub coś takiego jak VVV. Wszystko zależy od charakteru Twojej pracy.

Ponadto, w zależności od charakteru Twojej firmy, możesz mieć przypisane IDE wraz z różnymi plikami konfiguracyjnymi w celu egzekwowania określonych reguł.

A reszta środowisk?

Jak zwykle:

• rozwój odnosi się do instalacji na lokalnym komputerze,
• etapowanie odnosi się do obszaru, w którym Ty i interesariusze możecie testować,
• a produkcja jest tam, gdzie znajduje się aplikacja.

Ale wygląda to również inaczej w zależności od tego, gdzie pracujesz, jak zorganizowana jest Twoja praca i tak dalej. Nie chodzi o to, jak jest używany – chodzi o to, że jest używany.

Inscenizacja

Zazwyczaj jest to udostępniane na serwerze (lub grupie serwerów w zależności od rozmiaru projektu), na którym możesz wdrożyć najnowszy kod do testowania. Może zawierać częściową funkcjonalność, dane testowe i tylko podzbiór informacji z produkcji (jeśli zdecydujesz się pobrać te informacje, a mianowicie bazę danych, ze środowiska produkcyjnego).

Daje to Tobie i innym interesariuszom możliwość sprawdzenia, co się dzieje i jak będzie funkcjonować w produkcji, bez konieczności martwienia się o zniszczenie czegokolwiek wrażliwego.

Kod jest zwykle wdrażany z brancha, zwykle master, z twojego repozytorium Git (jeśli tego właśnie używasz). Narzędzia takie jak DeployBot, CircleCI, Travis CI, GrumPHP, Behat, itp. są również używane zarówno do oceny jakości kodu, przeprowadzania automatycznych testów, jak i ostatecznego wdrażania kodu.

W końcu każde środowisko będzie udostępniane w taki sposób, aby można je było szybko dublować na komputerach lokalnych, serwerach pomostowych i serwerach produkcyjnych. Co więcej, przenoszenie i przeciąganie danych między nimi powinno być łatwe, aby praca z nimi była łatwa.

Produkcja

Wreszcie produkcja dotyczy właściwie funkcjonującego projektu; Oznacza to, że serwer, aplikacja i baza danych działają razem i są używane przez użytkowników.

Oznacza to również, że kod znajduje się w stabilnym miejscu. Prawdopodobnie istnieją mechanizmy rejestrowania, które powiadomią zespół programistów o wszelkich problemach. Żadna zmiana kodu nie powinna następować w tym środowisku bez wcześniejszego przejścia kontroli jakości lub przygotowania.

A procesy w miejscu?

Ok, powiedzmy, że pracujesz z tradycyjną konfiguracją, z braku lepszego terminu, gdzie wszystkie twoje wdrożenia są wykonywane przez S/FTP w środowisku produkcyjnym (lub nawet postojowym). W ten sposób użytkownicy mogą ściągać pliki, wprowadzać zmiany i przesyłać je z powrotem.

To nie dobrze.

Oznacza to, że każdy, kto ma poświadczenia, może się zalogować, wprowadzać zmiany i omijać kontrolę źródła, ciągłą integrację, narzędzia zapewniania jakości itd. i wprowadzać dowolne zmiany.

Podważa wszystkie wprowadzone procesy. Ta procedura nie tylko omija standardową procedurę (która jest stosowana z jakiegoś powodu), ale kończy się łamaniem kodu, który programista lub zespół programistów ma na swoich komputerach, głównie dlatego, że to, co jest w produkcji, nie jest już zsynchronizowane z repozytorium kodu.

Co więcej, ten kod może być rozłożony na gałęzie, które nie zostały jeszcze scalone lub wdrożone. To pozostawia nam różne sytuacje, w których programiści i klienci zepsuli część procesu budowania, a tym samym cały projekt.

Kiedy przychodzi czas na sprawdzenie produkcji, nie jest ona zsynchronizowana z rozwojem i staczaniem, i nikt nie wie, dlaczego. Kiedy przychodzi czas na wdrożenie, zmiany są nadpisywane, a osoby odpowiedzialne straciły to, co myślały, że zobaczą.

Co ma zrobić zespół?

Nie wiem, czy jest na to jedna słuszna odpowiedź, ale im dłużej pracuję w tej branży, tym bardziej uważam, że firma – lub firmy – odpowiedzialne za zbudowanie rozwiązania dla klienta powinny mieć kontrolę nad procesem od końca- do końca.

• Projektanci są odpowiedzialni za zarządzanie swoimi obszarami tworzenia koncepcji, makiet, tworzenia szablonów demonstracyjnych i pozyskiwania informacji zwrotnych,
• Project Managerowie odpowiadają za komunikację z działami,
• Deweloperzy są odpowiedzialni za wdrożenie rozwiązania i powiązanie pracy projektantów z funkcjonalnym zapleczem,
• Klient jest odpowiedzialny za przeglądanie zmian, przekazywanie informacji zwrotnych i dostarczanie wszelkich innych informacji niezbędnych do wykonania zadania.

Oznacza to, że jeśli chodzi o konfigurację domeny, hosting, środowiska, kontrolę wersji, proces kompilacji i ciągłą integrację, i wszystko inne, o czym zapomniałem wspomnieć, należy wprost do zespołu programistów.

Trzymaj się okopów, trzymaj się celu (ale uważaj na osoby wokół ciebie).

Mówiąc najprościej, nie są to obowiązki klienta i nie powinny nimi być. Granice odpowiedzialności powinny być ustalane, utrzymywane i przestrzegane we wszystkich zespołach – nie tylko programistach i klientach lub klientach i projektantach lub projektantach i programistach i tak dalej.

Co dalej?

W następnym poście opowiem o odpowiedzialności programistów (i innych interesariuszy) za utrzymanie środowisk dla kodu.

Oznacza to, kto powinien być za co odpowiedzialny i kto ma dostęp do odczytu i zapisu jakich danych i jak może to ostatecznie wpłynąć na wynik projektu.