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

41

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.

druflex
źródło
To bardzo interesujące pytanie. To coś, co myślałem o wdrożeniu na mojej stronie internetowej, ale poddałem się, ponieważ nie wydawało się to wydajne. Jeśli przejdziesz przez to, daj nam swój wkład.
Tivie,
3
Zdecydowanie ciekawe pytanie, ale także trudne do odpowiedzi. Zadajesz wiele pytań, więc trudno jest podać pełną / najlepszą odpowiedź. Tylko jedna wskazówka: IMHO, żaden projekt nie jest zbyt mały do ​​kontroli wersji. Zwłaszcza teraz, gdy rozproszony system VCS, taki jak git, zajmuje około 5 sekund, aby umieścić kod w lokalnym repozytorium. Zobacz także drupal.stackexchange.com/questions/316/…
Berdir
Patrząc wstecz, w rzeczywistości żaden projekt nie jest zbyt mały do ​​kontroli wersji (gdybym tylko wtedy o tym wiedział). Przeszedłem przez ten link i rodzi to kolejne ważne pytanie. Jeśli mamy wyciągnąć rdzeń Drupala z jego własnego repozytorium git, czy powinniśmy używać git dla projektów Drupal zamiast SVN? Powodem, dla którego używamy SVN, jest fakt, że jest ono obsługiwane przez JIRA Studio, co jest dla nas ważne, ponieważ chcemy korzystać z funkcji automatycznej kompilacji JIRA (Elastic Bamboo). Przepraszamy za wiele pytań :-(
druflex
AKTUALIZACJA: Po przejrzeniu kodu ustalono, że w projekcie jest dużo kodu niestandardowego, którego eksportowanie za pomocą funkcji będzie naprawdę trudne. Tak więc przed nami są opcje - (1) Zakończ i wypuść, jak jest, i rozpocznij równoległy rozwój w D7 przy użyciu odpowiedniej kontroli wersji. Oznacza to później zakłócenie bazy danych. Straszny. (2) Wykonaj ponownie podstawowe funkcje w D6, zwolnij, a następnie wykonaj ciągłą integrację. (3) Wykonaj ponownie podstawowe funkcje w D7, zwolnij, a następnie wykonaj ciągłą integrację. Głównym pytaniem jest, ile czasu zajmie każda z tych opcji. Gdybyś był mną, na co głosowałbyś?
druflex

Odpowiedzi:

23

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.

Berdir
źródło
Dziękuję bardzo za tak świetną kompleksową odpowiedź. Prawie zdecydowałem, co dokładnie polecasz. Nawet włączając Gita. Przeniosę JIRA z hostowanej na samodzielną, aby móc korzystać z wtyczki Git. Więc to D6. Wypuść bieżącą wersję już teraz i zacznij od nowa równolegle tworzyć odpowiednią kopię najlepszych praktyk, używając jak największej liczby istniejących kodów. Jeszcze raz dziękuję za wsparcie. Twoje zdrowie!
druflex
+1 Dobra rada, wyczerpująca, praktyczna i realistyczna. Mówisz z doświadczenia. Dzięki.
therobyouknow