Czy najlepszą praktyką jest ręczne wdrażanie projektu na serwerze plik po pliku?

Firma, dla której obecnie pracuję, nie wdraża jeszcze ciągłej dostawy. Nadal wdrażamy projekt ręcznie na serwerze, plik po pliku. Jaka jest najlepsza praktyka: aby ręcznie wdrożyć jeden artefakt projektu dla każdego wdrożenia lub kontynuować wdrażanie plik po pliku?

Jaka jest najlepsza praktyka? ręcznie wdrożyć jeden artefakt projektu przy każdym wdrożeniu lub kontynuować wykonywanie pliku według wdrożenia pliku?

Ani.

Najlepszą praktyką jest zautomatyzowanie wdrożenia całkowicie i wyłącznie. Oznacza to, że nikt nie może ręcznie umieścić niczego na serwerze.

„Podsumowując streszczenie: Ludzie są problemem”. (Douglas Adams)

Ludzie popełniają błędy. Jeśli jeden z plików, o którym zapomnisz skopiować, to udostępniona „biblioteka”, która została znacznie zmieniona, możesz spowodować awarię całej witryny produkcyjnej.

Kroki ręczne wymagają dużego wysiłku i są ryzykowne: możesz zapomnieć o niezbędnym pliku. Może nie wszyscy w twoim zespole wiedzą, które pliki należy skopiować. Wszystkie te problemy sprawiają, że wdrożenia są duże, zniechęcające i rzadkie - całkowicie niepotrzebne. Automatyzacja rozwiązuje te problemy.

Nawet najprostszy krok automatyzacji może przynieść duże korzyści, ponieważ wdrożenia stają się banalne. Skrypt, który kopiuje pliki lub artefakty za pośrednictwem (S) FTP, Rsync lub innej technologii, to świetny pierwszy krok. Możesz później rozwinąć ten skrypt, aby automatycznie wykonać kroki przed i po instalacji na serwerze, takie jak ponowne uruchomienie usług.

Najlepszą praktyką byłoby wdrożenie pewnego rodzaju zautomatyzowanego procesu.

Uważaj, aby sprawdzić, czy nie ma specjalnego powodu dla podejścia „plik po pliku”, który musiałbyś wziąć pod uwagę.

Dzięki ciągłej dostawie (a właściwie wdrożeniu) i przenoszeniu każdego pliku ręcznie, patrzysz na dwie skrajności. Jest całkowicie zrozumiałe, że nie możesz / nie chcesz utworzyć w pełni zautomatyzowanego potoku (jeszcze). Należy jednak rozważyć zautomatyzowanie części procesu.

Ręczne przenoszenie każdego pliku jest dość ryzykowne i możesz zmniejszyć to ryzyko, na przykład, oznaczając repozytorium kodu, sprawdzając ten znacznik na komputerze, budując artefakty i przesyłając je na serwer. Każdy z tych kroków można zautomatyzować, tak aby wykonywano je kilkoma kliknięciami myszy, co znacznie zmniejszy ryzyko zapomnienia pliku lub przypadkowego popchnięcia w celu wygenerowania dodatkowych plików.

Zautomatyzuj to, co możesz, krok po kroku. Fakt, że nie stać Cię na w pełni zautomatyzowany potok CD, nie powinien zniechęcać Cię do automatyzacji niektórych części.

Najlepszą praktyką byłoby wykonanie analizy kosztów i korzyści dla konkretnego wdrożenia dla konkretnej firmy.

Ogólna odpowiedź brzmi: „nie rób rzeczy ręcznie, automatyzuj”. Jest to ogólnie właściwa odpowiedź dla ogólnych rodzajów firm. Jednorodność otrzymywanych odpowiedzi powinna wskazywać, jak silnie społeczność uznaje to za najlepsze praktyki. Jeśli Twoja firma uważa, że ​​automatyzacja nie jest właściwym narzędziem, powinna zrozumieć, co czyni ją wyjątkową. Ta wyjątkowość powinna zostać uwzględniona w procesie decyzyjnym. Nie ma „najlepszych praktyk”, gdy zestaw próbek ma wartość 1.

Pytania takie jak „ile plików” i „jak często rzeczy są aktualizowane” oraz „jakie są konsekwencje zepsucia” oraz „jak szybko można cofnąć złą zmianę” są ważnymi pytaniami, na które należy odpowiedzieć. W przypadku automatyzacji wiele z tych pytań staje się nieistotnych, ale są one niezbędne do prawidłowego przypisania kosztów i korzyści związanych z procesem ręcznej aktualizacji.

Istnieje wiele odcieni szarości pomiędzy ręcznym kopiowaniem plik po pliku a ciągłym dostarczaniem.

Zacznij od zmniejszenia złożoności procesu wdrażania, na przykład poprzez użycie pliku zip, pakietu w stylu rpm, infrastruktury jako narzędzia do zarządzania kodem (takiego jak marionetka lub szef kuchni) lub nawet po prostu prostego skryptu, który kopiuje pliki z obszar przejściowy na serwerze ftp.

Procesy wdrażania z większą liczbą ręcznych kroków są bardziej podatne na błędy (a tym samym niepowodzenie) - jak inni powiedzieli, usuń z tego element ludzki.

Nie musisz wdrażać pełnej ciągłej dostawy (co jest kosztowne i wymaga wysiłku / inwestycji / innowacji w czasie) - zacznij od prostoty, spraw, by działało, pokaż korzyści - i stamtąd.

Zależy to od używanej technologii oprogramowania (lub stosu) (język interpretowany, język kompilowany, aplikacja komputerowa, urządzenia mobilne itp.), Miękki. dev. zasady działów, jeśli masz narzędzia do automatyzacji, jak ważna jest twoja aplikacja, a jedną ważną rzeczą do rozważenia jest architektura oprogramowania (sposób zaprojektowania aplikacji). Dlatego masz tutaj różne odpowiedzi. Zasadniczo najlepszym podejściem będzie zmniejszenie interwencji człowieka w zadania związane z wdrażaniem, aby uniknąć błędów. Dobrą praktyką będzie testowanie wszystkiego na serwerze QA Server (rozważ użycie serwera wirtualnego, jeśli budżet stanowi problem) przed wdrożeniem oraz zastosowanie procedur odwrotnych w celu przywrócenia poprzedniej wersji w przypadku awarii ( ZAWSZE mają kopię zapasową).