ulepszyć naszą strategię wdrażania

Mamy aplikację e-commerce, którą rozwijamy w naszej firmie. Jest to w miarę standardowa aplikacja LAMP, którą rozwijamy z przerwami od około 3 lat. Tworzymy aplikację w domenie testowej, tutaj dodajemy nowe funkcje i naprawiamy błędy itp. Nasze śledzenie błędów i opracowywanie funkcji jest zarządzane w ramach hostowanego rozwiązania subversion (unfuddle.com). Ponieważ zgłaszane są błędy, wprowadzamy poprawki w domenie testowej, a następnie zatwierdzamy zmiany w svn, gdy jesteśmy zadowoleni, że błąd został naprawiony. Postępujemy zgodnie z tą samą procedurą, dodając nowe funkcje.

Warto tu wskazać ogólną architekturę naszego systemu i aplikacji na naszych serwerach. Za każdym razem, gdy opracowywana jest nowa funkcja, wprowadzamy tę aktualizację do wszystkich witryn korzystających z naszej aplikacji (zawsze serwer, który kontrolujemy). Każda strona korzystająca z naszego systemu zasadniczo używa dokładnie tych samych plików dla 95% bazy kodu. W każdej witrynie znajduje się kilka folderów, które zawierają pliki dostosowane do tej witryny - pliki / obrazy css itp. Poza tym różnice między poszczególnymi witrynami są określone przez różne ustawienia konfiguracji w bazie danych każdej witryny.

To dotyczy samego wdrożenia. Gdy jesteśmy gotowi do wprowadzenia jakiejś aktualizacji, uruchamiamy polecenie na serwerze, na którym znajduje się strona testowa. Wykonuje to polecenie kopiowania (cp -fru / testsite / / othersite /) i przechodzi przez każdy vhost wymusza aktualizację plików na podstawie zmodyfikowanej daty. Każdy dodatkowy serwer, na którym hostujemy, ma vhost, do którego synchronizujemy bazę kodu produkcyjnego, a następnie powtarzamy procedurę kopiowania na wszystkich stronach na tym serwerze. Podczas tego procesu usuwamy pliki, których nie chcemy zastąpić, przenosząc je z powrotem po zakończeniu kopiowania. Nasz skrypt wdrażania wykonuje szereg innych funkcji, takich jak stosowanie poleceń SQL w celu zmiany każdej bazy danych, dodawanie pól / nowych tabel itp.

Coraz bardziej martwimy się, że nasz proces nie jest wystarczająco stabilny, nie jest odporny na uszkodzenia i jest również metodą siłową. Zdajemy sobie również sprawę, że nie wykorzystujemy najlepiej subversion, ponieważ praca nad nową funkcją uniemożliwiłaby nam wprowadzenie ważnej poprawki błędów, ponieważ nie korzystamy z gałęzi ani tagów. Wydaje się również niewłaściwe, że mamy tak dużo replikacji plików na naszych serwerach. Nie jesteśmy również w stanie łatwo cofnąć tego, co właśnie wprowadziliśmy. Wykonujemy różnicę przed każdym wdrożeniem, abyśmy mogli uzyskać listę plików, które zostaną zmienione, abyśmy wiedzieli, co zostało zmienione po, ale proces przywracania byłby nadal problematyczny. Jeśli chodzi o bazę danych, zacząłem szukać dbdeploy jako potencjalnego rozwiązania. Jednak tak naprawdę chcemy kilku ogólnych wskazówek, w jaki sposób możemy ulepszyć zarządzanie plikami i ich wdrażanie. Idealnie byłoby, gdyby zarządzanie plikami było ściślej powiązane z naszym repozytorium, aby rollout / rollback był bardziej powiązany z svn. Coś jak użycie polecenia eksportowania, aby upewnić się, że pliki serwisu są takie same jak pliki repo. Byłoby również dobrze, gdyby rozwiązanie mogło zatrzymać replikację plików wokół naszych serwerów.

Ignorując nasze obecne metody, dobrze byłoby usłyszeć, jak inni ludzie podchodzą do tego samego problemu.

podsumować ...

• Jaki jest najlepszy sposób na synchronizację plików na wielu serwerach z svn?
• Jak powinniśmy zapobiec replikacji plików? dowiązania symboliczne / coś jeszcze?
• Jak powinniśmy ustrukturyzować nasze repozytorium, abyśmy mogli opracowywać nowe funkcje i naprawiać stare?
• Jak powinniśmy uruchamiać roll-roll'y?

Z góry dziękuję

EDYTOWAĆ:

Czytałem ostatnio wiele dobrych rzeczy na temat używania Phing i Capistrano do takich zadań. Czy ktoś może podać więcej informacji na ich temat oraz o tym, jak dobry byłby do tego rodzaju zadań?

Moja rada dotycząca robienia wydań to posiadanie wydań funkcji i wydań związanych z konserwacją. Wydawaniami nowych funkcji byłyby wydania, które mają nowe funkcje. Zostaną dodane do twojego pnia subversion. Gdy uważasz, że są one ukończone, rozgałęziasz je na gałąź wydania. Gdy proces kontroli jakości będzie satysfakcjonujący dzięki tej wersji, oznacz ją i umieść kod na swoich serwerach.

Teraz, gdy pojawi się raport o błędzie, zatwierdzasz tę poprawkę do gałęzi i przenosisz ją do pnia. Gdy jesteś zadowolony z liczby naprawionych błędów, możesz oznaczyć i wdrożyć wydanie serwisowe.

Ważne jest, aby mieć gałąź bazy kodu aktywnego (lub mieć możliwość jej utworzenia, znając wersję live), która jest niezależna od gałęzi programistycznej, aby mieć możliwość wdrażania poprawek do kodu aktywnego bez konieczności wdrożyć nowe funkcje lub nieprzetestowany kod.

Polecam użycie natywnego systemu pakowania twojej dystrybucji do wdrożenia nowego kodu. Jeśli masz pakiet zawierający całą bazę kodu, wiesz, że cały kod został wdrożony w ramach operacji atomowej, możesz zobaczyć, która wersja jest zainstalowana na pierwszy rzut oka, możesz zweryfikować bazę kodu za pomocą sumy kontrolnej pakietów. Cofanie jest tylko przypadkiem instalacji poprzednio zainstalowanej wersji pakietu.

Jedyną przeszkodą, jaką widzę w tej sprawie, jest to, że masz wiele kopii bazy kodu dla różnych klientów działających na jednym serwerze. Spróbowałbym tak ułożyć kod, aby wszyscy klienci korzystali z tych samych plików i nie używali kopii. Nie wiem, jak by to było dla ciebie łatwe, ale zmniejszenie liczby kopii, z którymi masz do czynienia, znacznie zmniejszy Twój ból głowy.

Zakładam, że jak wspomniałeś LAMP, używasz PHP lub innego języka skryptowego, który nie wymaga procesu kompilacji. Oznacza to, że prawdopodobnie brakuje Ci cudownego procesu zwanego Continuous Integration. Zasadniczo oznacza to, że Twój kod jest ciągle testowany, aby upewnić się, że jest w stanie możliwym do zwolnienia. Za każdym razem, gdy ktoś sprawdza nowy kod, proces bierze go i uruchamia proces kompilacji i testowania. W języku kompilowanym zwykle używasz tego, aby upewnić się, że kod jest nadal kompilowany. W każdym języku powinieneś skorzystać z okazji do przeprowadzenia testów jednostkowych (twój kod jest w testowalnych jednostkach, prawda?) I testów integracyjnych. W przypadku stron internetowych dobrym narzędziem do testowania testów integracyjnych jest Selenium. W naszych kompilacjach Java mierzymy również pokrycie kodu i jego metryki, aby zobaczyć, jak postępujemy w czasie. Najlepszym serwerem CI, jaki znaleźliśmy dla Javy, jest Hudson, ale coś takiego jak buildbot może działać lepiej w innych językach. Możesz budować pakiety za pomocą serwera CI.

Zaczęliśmy używać Puppet (flagowego produktu Reductive Labs). Jest to platforma oparta na Ruby do automatyzacji zadań sys-admin. Byłem na puppetcamp kilka tygodni temu i oto linki wideo:

Luke Kanies Presenting - Puppet Intro

Ponadto, jeśli chcesz zobaczyć wszystkie prezentacje wykonane w puppetcamp w San Francisco, ten link:

Prezentacje na temat tego, jak inni używali Puppet

Cieszyć się.