Muszę doprowadzić witrynę do kontroli wersji i skonfigurować środowisko ciągłej integracji

Jestem przedsiębiorcą z projektem Drupal 6x, który rozpoczął się na tyle mały, że nie potrzebował kontroli wersji (na programistów), ale teraz jestem przekonany, że bez niego nie ma mowy. Istnieje obszerna dokumentacja na temat JIRA, wraz z dobrze napisanymi historiami użytkowników obejmującymi wszystko. Przeczytałem trochę o tym, jak można to zrobić i opracowałem następujący plan -

1. Oddziel kod witryny od bazy danych za pomocą modułów
   1. Kontekst
   2. cechy
   3. Silne ramie
   4. Profiler
2. Umieść kod w repozytorium SVN i utwórz witrynę pomostową
3. Utwórz kopię lustrzaną serwera pomostowego na serwerze produkcyjnym EC2
4. Twórz testy selenu i uruchamiaj je w chmurze za pomocą Saucelabs
5. Utwórz przepływ pracy kompilacji w JIRA Studio za pomocą Elastic Bamboo, aby uruchomić automatyczne aktualizacje
6. Zaktualizuj i zainstaluj profile za pomocą Drush Make
7. Uruchom aktualizacje na serwerze produkcyjnym (nie jestem pewien jak)

Na początek stworzyłem listę około 50 „Funkcji”, z których każda zawiera elementy (widoki, typy zawartości, moduły itp.). Będzie to bez wątpienia trudne, ponieważ witryna zawiera około tuzina niestandardowych modułów i usług internetowych, nie wspominając o kolejnych tuzinach wystąpień „aplikacji” typu treści zawierających niestandardowy kod (z których większość chciałbym przekonwertować na widoki lub moduły z możliwością aktualizacji) . Dobrą rzeczą jest to, że strona nie jest jeszcze produkowana, więc ryzyko jest nadal ograniczone.

Czy ktoś ma jakieś doświadczenie w robieniu czegoś podobnego? Jakie pułapki i ograniczenia należy się spodziewać? Byłbym bardzo wdzięczny za wszelkie sugestie dotyczące ulepszenia / skorygowania powyższego planu, a także za wszelkie spostrzeżenia lub porady, które mogą dla mnie uzyskać eksperci.

Ok, spróbuję :) Nie będę w stanie w pełni odpowiedzieć na twoje pytanie, ale może dam ci kilka interesujących wskazówek. Pamiętaj, że moja numeracja nie jest bezpośrednią odpowiedzią na Twoją :)

1. Jak już wspomniałem w komentarzu, żaden projekt nie jest zbyt mały do ​​kontroli wersji. Osobiście polecam Git. Powodem jest po prostu niesamowita szybkość (czas oczekiwania w git jest mierzony w milisekundach, a nie sekundach) i ogromna liczba funkcji. Może być trochę trudny do uchwycenia z powodu dziwnych nazw i argumentów, ale poniższa dokumentacja wyjaśnia wiele z nich naprawdę dobrych: http://www.eecs.harvard.edu/~cduan/technical/git/ . Innym powodem jest to, że jest teraz używany przez drupal.org, więc znajomość git pomoże ci, gdy będziesz chciał wesprzeć (dostarczając łatki, łatki testowe, moduły wydania ...)

2. To powiedziawszy, jeśli chcesz użyć SVN z jakiegoś powodu (np. Integracji z usługami, z których zamierzasz korzystać), to idź. SVN działa również rozsądnie i jest znacznie lepszy niż brak kontroli źródła. (Chyba że poprosisz Linusa Torvaldsa ...). Ponadto, jeśli zmienisz zdanie, często istnieją sposoby migracji z jednego VCS do drugiego. SVN -> Git działa na przykład dobrze.

3. Po trzecie, podejdź do tego krok po kroku. Nie próbuj robić wszystkiego naraz. Daj tobie (i programistom) czas na naukę nowych narzędzi.

4. Przejście z Drupal 6 na Drupal 7 nie jest trywialne. Zwłaszcza z dużą ilością niestandardowego kodu. Należy pamiętać, że istnieje mnóstwo zmian API i nowych koncepcji (takich jak system encji / pól), jest też kwestia, że ​​wiele wniesionych modułów nie jest jeszcze w pełni gotowych.

5. Zarządzanie wdrażaniem jest jednym ze słabych punktów Drupala, który również nie zmienił się tak bardzo w Drupal 7. Jesteśmy świadomi problemu i ludzie ciężko pracują, aby rozwiązać ten problem w Drupal 8: http://groups.drupal.org / build-systems-change-management / cmi . Funkcje itp. Pomagają, ale to nie jest srebrna kula. Nie wszystko można wyeksportować jako funkcję.

6. Istnieje również kilka opcji specyficznych dla Drupala dotyczących wdrażania miejsc postoju / produkcji. Warto sprawdzić Panteon (wciąż w fazie beta) i Acquia Dev Cloud .

7. Ciągła integracja, automatyczne testowanie jest ważne i bardzo przydatne, ale wymaga również czasu na skonfigurowanie, napisanie testów i tak dalej. Czas, który możesz mieć lub nie w tym momencie. Ale szczególnie zautomatyzowane testy to obszar, w którym łatwo jest wprowadzać stopniowe ulepszenia. Po skonfigurowaniu środowiska do ich uruchamiania możesz pisać coraz więcej testów w miarę upływu czasu.

Oto moja rekomendacja do zaktualizowanego pytania w komentarzu:

Zakończ i wypuść jak jest, ale zacznij używać VCS (system kontroli wersji) dla Drupala 6 już teraz. Utwórz środowisko przejściowe dla swojej witryny. Sprawdź, jakich modułów (współtworzysz) używasz i sprawdź, czy port w Drupal 7 jest w tym momencie możliwy. Nie lekceważ czasu, który to zajmie. Rozpocznij także usprawnianie procesu testowania / wdrażania, zaczynając od tego, co Twoim zdaniem przyniesie Ci najwięcej korzyści / kosztów.

Możesz także utworzyć bardziej szczegółowe pytania uzupełniające lub przejrzeć te, które już istnieją. Jak widać, nawet podanie kilku wskazówek na takie pytanie może stać się ogromne i zająć sporo czasu.