Czy można wdrożyć aplikację internetową do produkcji bezpośrednio z SVN

Pytanie

Czy istnieje uzasadniony powód, aby NIE używać SVN do wdrożeń produkcyjnych, czy jest to tylko przypadek osobistych preferencji i nie ma prawdziwego argumentu przeciwko SVN?

tło

Moje miejsce pracy ma kulturę oznaczania wersji w SVN, a następnie wdrażanie tych wersji bezpośrednio na różnych serwerach internetowych przy użyciu svn colub svn switchbezpośrednio do produkcji.

Osobiście mam z tym problem, ponieważ uważam, że bez użycia skryptu kompilacji i wdrażania lub jakiejkolwiek formy lub wdrożenia automatycznego tracisz ustawienia środowiska integracji, ponieważ są one nieudokumentowane. Co więcej, mam przeczucie, że może istnieć ukryte niebezpieczeństwo zrobienia tego, co zostało przeoczone, czegoś, co jeszcze nie pochyliło swojej brzydkiej głowy.

Podniosłem swoje obawy dotyczące personelu operacyjnego, który jest odpowiedzialny za wdrażanie kodu w różnych środowiskach (inscenizacja, pre-prod, produkcja) itp. Ich argumenty były dość duże, że jak dotąd działał całkiem dobrze, bez powodu, aby to zmieniać.

Edytować:

Co mam na myśli mówiąc o kompilacji i wdrożeniu:

Na przykład, jeśli programista wymaga ustawienia web.config dodanego dla określonego środowiska. Web.config zasadniczo nie jest przechowywany w svn, dlatego te pliki są aktualizowane ręcznie bez jakiejkolwiek formy skryptu automatycznej kompilacji. Więc jeśli zostaną zgubione lub OPS zapomni dodać pola do pliku web.config dla wydania, masz problemy.

Skrypt kompilacji, który mówi, że używa XMLPoke do automatycznego generowania pliku web.config odpowiedniego dla określonego środowiska, jest idealny, ponieważ masz skrypt z możliwością aktualizacji, który dokumentuje wszystkie zmiany niezbędne dla każdego z twoich środowisk.

Bieżąca metoda kompilacji i wdrożenia

W przypadku omawianego projektu deweloper buduje wydanie ręcznie, w innych projektach etap kompilacji jest zautomatyzowany za pomocą NANT lub MSBuild, co jest w porządku.

Migracje baz danych dla większości projektów odbywają się za pomocą skryptów DB lub skryptów migracji (Migrator.NET) lub pakietów CMS.

CI jest zwykle wykonywane przez Team City na podstawie odprawy, mamy proces sprawdzania kodu, że wszystkie bilety są wykonywane w oddziałach, a następnie sprawdzane pod kątem weryfikacji i poprawności / jakości przed sprawdzeniem w bagażniku (działa dobrze).

Jednak rzeczywiste wdrażanie kodu odbywa się prawie zawsze za pośrednictwem SVN, albo poprzez pobranie oznaczonego wydania lub, bardziej ogólnie, Przełącznik SVN. Jest to dla mnie dziwne, że używamy naszego repozytorium w ramach procesu wdrażania.

Konfiguracja zazwyczaj nie zmienia się bardzo często, jedyne, co będzie w plikach konfiguracyjnych, to informacje specyficzne dla środowiska. Cała reszta jest w db.

Nie zrozum mnie źle, to działa, działa dobrze. Jednak chcę spróbować naciskać na automatyczną kompilację i wdrożenie. Użyłem tego z Railsami i Capistrano oraz do osobistych projektów wykorzystujących Cygwin, Nant i SSH.

Co ważniejsze, potrzebuję bardzo konkretnych, ważnych argumentów, aby zachęcić moich kolegów do korzystania z zautomatyzowanej kompilacji i wdrożenia.

Czy też nie ma ŻADNYCH prawdziwych argumentów przeciwko używaniu SVN specjalnie do wdrożenia w produkcji?

Z mojego doświadczenia wynika, że ​​zarówno zalety, jak i wady:

Plusy:

• Czasami wprowadzasz pilne poprawki na serwerze produkcyjnym, a następnie możesz je sprawdzić bezpośrednio z tego miejsca. (Chociaż teoretycznie, ze względów bezpieczeństwa zawsze dobrym pomysłem jest korzystanie z dostępu tylko do odczytu do repozytorium z serwera produkcyjnego).

• Prostota: dostarczasz szybko, chociaż jak wspomniano tutaj, przejście na schemat skryptu aktualizacji może być równie łatwe.

Cons:

• Twój system może stać się niestabilny podczas svn upaktualizacji i aktualizacji DB. W przypadku witryny o dużym ruchu oznacza to, że niektórzy użytkownicy będą co najwyżej wyświetlać komunikaty o błędach, uszkodzone strony lub puste strony. Cóż, to bardzo często widzimy w różnych usługach społecznych. Dobra usługa robi jednak „atomowo” w tym sensie, że wprowadza system w tryb konserwacji na czas aktualizacji. ( Złamałeś reddita! )

• Konflikty: rozwiązywanie nagłych konfliktów na serwerze produkcyjnym to okropny pomysł: ponownie usługa staje się niestabilna podczas jej naprawiania.

• Niepowiązane pliki na serwerze produkcyjnym, które mogą należeć do Ciebie, ale oczywiście możesz tego uniknąć, sprawdzając odpowiednie poddrzewo w repozytorium.

• Bezpieczeństwo: ktoś, kto uzyskał dostęp do twojego serwera produkcyjnego, legalnie lub nie, również uzyskuje dostęp do twoich repozytoriów, ewentualnie innych produktów, a także ewentualnie z prawem do zapisu! Ogólne otwarcie wewnętrznego serwera SVN na świat zewnętrzny to zły pomysł. Twoje repozytoria źródłowe powinny znajdować się za zaporą firmy, kropka.

• W każdym razie pojawią się skrypty aktualizacji, np. Do aktualizacji struktury DB, zarządzania cronjobs itp. Dlaczego więc nie mieć skryptu, który to wszystko robi? - tj. ściąga najnowszą paczkowaną wersję, przełącza się w tryb konserwacji, aktualizuje źródła, uruchamia skrypty specyficzne dla wydania itp.

Edycja: dla tych, którzy nadal korzystają ze schematu SVN, nie zapomnij tego w konfiguracji apache:

<DirectoryMatch .svn>
    Order deny,allow
    Deny from all
</DirectoryMatch>

W swojej pracy skonfigurowałem serwer CI, który automatycznie tworzy nasz instalator, zakładając, że testy jednostkowe przebiegły pomyślnie. Zajęło mi to około jeden dzień pracy i zaoszczędziło mi o wiele więcej, odkąd go skonfigurowałem.

Jeśli podczas konfigurowania witryny z wersją / instalatorem / produkcją istnieje jakikolwiek proces ręczny, niezmiennie oszczędzasz czas siebie i firmy. Jest to odpowiednie dla Ciebie, ponieważ z twojego pytania wynika, że ​​w procesie instalacji są kroki konfiguracji ręcznej.

W celach informacyjnych zobacz, jak sam Joel opowiada o tym, jak proces kompilacji jednym kliknięciem oszczędza Cię w perspektywie krótko- i średnioterminowej.

Upewnij się, że masz odpowiednie opcje kontroli w SVN. Rozważ na przykład:

• Funkcje są sprawdzane w celu wydania
• Kod jest wdrażany do przemieszczania, kontrola jakości wykonuje swoje zadanie
• Błędy zostały naprawione, kolejna runda testowania (jednak działa w twoim zespole)
• To samo dotyczy pre-prod
• Wdróż w produkcji

Jeśli ktoś przypadkowo dokona rezerwacji po etapie przedprodukcyjnym, istnieje ryzyko, że coś zepsuje. Jeśli jest to kontrolowane - ponieważ nie jest dozwolone sprawdzanie podczas pre-prod poza poprawkami błędów - nie widzę żadnego ryzyka.

Aktualizacja: Masz problem z oczekiwaniem, jeśli nie zameldujesz plików konfiguracyjnych. Naprawdę nie mogę zaoferować żadnych porad innych niż „proszę, zrób to szybko!”

Wydaje się być w porządku, o ile nie ma nic poza repozytorium. Rzeczywiście, uważam, że nie należy inwestować czasu w narzędzia wdrażania przez kilka pierwszych miesięcy projektu. Ponieważ będzie zbyt wiele wdrożeń, za mało klientów, aby przeszkadzać im w formalnym procesie wydania.

Ale kiedy projekt ma około roku, warto rozważyć zainwestowanie w narzędzie do wdrażania. Proste powody to

• Rozwija się biznes, więc planujesz hostować go na więcej niż jednym serwerze
• Mogą występować błędy w określonym środowisku i nie masz miejsca na replikację błędu. Nie ma łatwego sposobu na skonfigurowanie go bez procesu tar-untar-forget_about_home_for_a_week.
• Ktoś prawdopodobnie zepsuje kompilację. Kto złamał kompilację

Jeśli chcesz ich przekonać, poproś o skonfigurowanie innego serwera do testów wewnętrznych lub kontroli jakości.