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ń?