Kontrola wersji dla rozwoju modułów

Zastanawiam się, czy istnieją jakieś dobre konwencje, jeśli chodzi o kontrolę wersji, dotyczące opracowywania modułu, którego używasz zarówno w jednej instancji Magento, jak i który chcesz wydać jako moduł społecznościowy.

Początkowo próbowałem użyć modmana do zarządzania modułem poza moim głównym repozytorium instancji Magento. Ale skończyło się to problematycznie na wielu poziomach. Posiadanie pojedynczego repozytorium, które można łatwo zainstalować w różnych środowiskach lub wycofać z produkcji, jest niezwykle przydatne, a nawet powiedziałbym, że stało się niezbędną częścią mojego przepływu pracy.

To, co obecnie robię, polega na rozwijaniu go w moim repozytorium witryny i planuję wkrótce podzielić go na osobne repozytorium. W tym momencie prawdopodobnie zrobię to:

• Wbuduj w moim lokalnym środowisku w ramach indywidualnego repozytorium modułów za pomocą modmana
• Skopiuj zmiany do repozytorium witryny, gdy będę gotowy do wdrożenia kodu

Mając nadzieję, że istnieje lepszy sposób?

Mamy kilka modułów, w których to zrobiliśmy i zasadniczo to zrobiliśmy:

• Skonfiguruj repozytorium Git dla modułu.
• Wdróż ten moduł w bazie kodu witryny produkcyjnej i zatwierdź wszystko, w tym:
  • miękkie linki utworzone przez modmana
  • katalog .modman, w którym znajduje się sklonowane repozytorium modułów
• Użyj modmana, aby „wdrożyć” go w innych wersjach i / lub środowisku deweloperskim na potrzeby tworzenia i testowania.

W ten sposób zyskujesz elastyczność potrzebną do rozwoju modułu, wersjonuje również kod w pojedynczej witrynie, a jeśli wprowadzisz zmiany w module w bazie kodu w pojedynczej witrynie, możesz zatwierdzić je bezpośrednio z powrotem do repozytorium modułów, ponieważ repozytorium znajduje się w katalogu .modman.

AKTUALIZACJA: Kiedy pierwotnie to napisałem, w mojej odpowiedzi nie wziąłem pod uwagę, że Git nie zezwala na (pod) moduły na repozytorium, w którym to przypadku rodzaj „popełniania wszystkiego” wymaga pewnego dopracowania!

Nawiasem mówiąc, dzieje się tak dlatego, że robiłem to częściej, używając modmana do wdrażania modułów przechowywanych w repozytoriach Git w produkcyjnej bazie kodu znajdującej się w SVN… a Subversion nie ma żadnych skrupułów uniemożliwiających przesłanie całego drzewa Git do VCS.

Więc oto idzie…

1. Jeśli używasz SVN do przechowywania kodu witryny produkcyjnej, nie powinieneś mieć problemów, ponieważ Subversion (praktycznie) nie ma koncepcji podmodułów. To nie będzie przeszkadzało.

2. Jeśli używasz Gita do kodu witryny produkcyjnej, będziesz musiał użyć podmodułów, aby „zatwierdzić wszystko” do repozytorium kodu witryny. Po użyciu modmana do klonowania czegoś takiego:

   modman clone ssh://git@bitbucket.org/<user>/<repo>.git

   Będziesz także chciał dodać go jako podmoduł:

   git submodule add ssh://git@bitbucket.org/<user>/<repo>.git .modman/<repo>

   Gdy to zrobisz, powinieneś być w stanie dodać katalog .modman i plik .gitmodules do indeksu i zatwierdzić go.

   Po sklonowaniu repozytorium, które używa tych modułów zainstalowanych za pomocą modmana, po prostu uruchom submoduły i zaktualizuj:

   git submodule init
   git submodule update

PS Teraz korzystam z Git w pełnym wymiarze godzin we wszystkich nowych projektach, więc mam nadzieję, że ten nadzór się nie powtórzy. Przepraszam chłopaki. ;)

Wydaje się, że obecna konwencja ma wspierać:

• Kompozytor - http://getcomposer.org/
• Modman - https://github.com/colinmollenhour/modman
• Repozytorium Github

Jeśli chodzi o strukturę katalogów, jest to minimum, a najlepiej moduł jest zainstalowany w puli kodów społeczności.

Sugerowana minimalna struktura katalogów to:

.
└── app
    ├── code
    │   └── community
    │       └── YourCompany
    │           └── YourModule
    │               ├── Block
    │               ├── Model
    │               │   └── Observer.php
    │               └── etc
    │                   └── config.xml
    ├── design
    │   └── frontend
    │       └── base
    │           └── default
    │               ├── layout
    │               │   └── module.xml
    │               └── template
    │                   └── yourmodule
    └── etc
        └── modules
            └── YourCompany_YourModule.xml

Opcjonalne / przyjemne dla oka:

• Strona docelowa Github z opisem, zrzutami ekranu i niektórymi wypunktowanymi funkcjami.
• Przyłączenie się do zainstalowanego sklepu demonstracyjnego również byłoby fajne
• Screencast / dwuminutowy przegląd twojego produktu

Edycja: Być może źle zrozumiałem.

Używanie kombinacji modman / gitignore może utrzymać moduł w izolacji od środowiska testowego. Korzystając z powyższej struktury folderów, możesz jawnie zezwolić na zatwierdzenie / instalację tylko plików modułu na repozytorium. W tym przypadku odpowiedź Davida jest bardziej odpowiednia. Wydaje się, że wsparcie Modmana dla dev / deploy jest zgodne.

Nawet jeszcze tego nie próbowałem, polecam do tego kompozytora .

Wersjonowanie, w tym zależności

Trzymając composer.lockplik w repozytorium, naprawiasz wersje wszystkich modułów i zawsze możesz przywrócić określoną wersję (gałąź, znacznik lub starszą wersję) za pomocą VCS ( git checkout, svn ..), a następnie composer.phar install.

Wady

Powstaje problem polegający na tym, że wdrożenie może łatwo zależeć od wielu źródeł (na przykład GitHub), tworząc wiele punktów awarii.

Potrzebowalibyśmy więc pamięci podręcznej lub serwera proxy, w którym przechowywane są te moduły, dzięki czemu zawsze możemy je wdrożyć.

Satis wydaje się być w stanie służyć temu celowi (patrz https://github.com/researchgate/broker ) i moje pytanie /programming//q/16211671/288568

Kalen,

Być może nie do końca zrozumiałem twój przebieg pracy, ale brzmiało to tak, jakbyś rozwijał się lokalnie w repozytorium magento, a następnie rozdzielił się na repozytorium modman. Dlaczego nie po prostu edytować ./modman/modulesname/CONTENTS w twoim IDE i wypchnąć kod do repozytorium modułu niezależnie w tym samym przepływie pracy, którego używasz do programowania. możesz użyć modmana do wdrożenia do produkcji, możesz wchodzić w interakcje z indywidualnym repozytorium w folderze .modman / modulesname / z cli lub dodając źródło kontroli wersji do swojego IDE, chociaż tak naprawdę używając .basedir, aby utrzymać ścieżki do repozytorium poza twoim webroot będzie grał lepiej.

Jest też naprawdę fajna funkcja modmana, z której wielu ludzi nie korzysta. Skrypt bash interpretuje plik .basedir w repozytorium .modman, jeśli plik nie istnieje, modman stosuje reguły dowiązania symbolicznego w pliku modman na tym samym poziomie co folder .modman ... jeśli plik .basedir istnieje, zawartość opisuje podfolder, który jest najwyższym poziomem twojego kodu Magento jeden poniżej ścieżki .modman ... innymi słowy, możesz uruchomić (i ja) wszystkie podstawowe wersje Magento w folderach takich jak „BaseMagento1.9.1.0” „BaseMagento1.14.2.0” i modman inicjują folder zawierający je. Dodaj plik .basedir do ścieżki .modman, aby łatwo zmieniać zawartość. Działa to dobrze w przypadku testowania wersji.