Kontrola wersji dla Smalltalk/Seaside?

Question

Jestem przede wszystkim programistą Java EE. Zostałem poproszony o zbadanie możliwości wykorzystania Smalltalk/Seaside w nadchodzącym projekcie internetowym. Jak można sobie wyobrazić, doprowadziło to do wielu interesujących pytań.

W jaki sposób zespół programistów wdraża wersjonowanie oprogramowania i kontrolę wersji za pomocą Smalltalk/Seaside. Czy możesz użyć Subversion lub Git?

Z tego co rozumiem, Smalltalk używa obrazu zamiast zapisywania każdej klasy do własnego pliku. Jak to wpływa na możliwość zarządzania wersjami kodu źródłowego, w szczególności w zespole?

Wielkie dzięki za wszelkie informacje, które możesz dostarczyć!

Answer 1

Instalator dla Pharo (i Gemstone)

każdy programista pracuje na swój obraz. Każda zmiana metody, którą tworzy, jest zapisywana lokalnie w pliku zmian. Pozwala to odzyskać po awarii obrazu. Zatwierdzenia dokonuje się, tworząc plik monticello, zawierający nazwę pakietu, numer kolejny i nazwę programisty. Zna jego pochodzenie. Ten plik zostanie zapisany na serwerze WebDAV. Tutaj jest odbierany przez Jenkins task. To uruchamia test jednostki i integracji i tworzy nowe obrazy, dzięki czemu programiści mogą zacząć od świeżego obrazu (przynajmniej) każdego dnia. Oto kilka szczegółów na temat merging przy użyciu monticello. Skład produktu (struktura paczki) to kolejny plik monticello zawierający opis: metacello. Pozwala to również rozwijać się na Pharo i wdrażać na Gemstone. Od czasu do czasu musisz dodać migracje klas.

Dla zależnościami non-Smalltalk i rozwoju, akceptacji testu i różnic produkcyjnych, dodaj tworzenie obrazów VirtualBox korzystających vagrant, chef-solo (lub puppet, mam nadzieję, że wkrótce Coral), veewee. Są oczywiście w wersji zarządzanej przy użyciu git.

Oprócz korzystania statycznych narzędzi kontroli kodu jakości (smallLint, sprawdza również różnice między dialektami Smalltalk), dodać Moose i stworzyć swój własny kontekst zależny, dynamiczne wizualizacje projektu (humane assessment)

W VisualWorks Smalltalk lokalnego dewelopera używa STORE z relacyjną bazą danych (np. PostgreSQL) do przechowywania lokalnych zatwierdzeń. Kod jest zorganizowany w pakiety pakietów z przestrzeniami nazw. Skrypt replikacji służy do kopiowania lokalnych wersji do iz centralnej bazy danych. Stamtąd przepływ jest taki sam jak w konfiguracji Pharo.

[aktualizacja] W Esug2012, Dale Henrichs zaprezentował pracę, aby umożliwić używanie git i github do zarządzania kodem smalltalk dla wielu dialektów. Zasadniczo zdefiniowano strukturę plików (Cypress dla Amber, Gemstone, Pharo, Squeak, VisualAge, STIG dla VisualWorks) do przechowywania metod smalltalk w katalogach. Obecnie ma to na celu bardziej wymianę kodu między dialektami niż zastąpienie natywnego SCM.

Answer 2

Smalltalk ma własne systemy pakowania/wersjonowania, w których pakiety kodu źródłowego są pod kontrolą, dzielone, scalane itp. Które dialekty Smalltalk zamierzasz użyć? Pharo ma Monticello i Metacello, Squeak ma Monticello, VisualWorks ma STORE.

Answer 3

VA Smalltalk ma Envy.

Który z wybieranych przez ciebie produktów Smalltalk, myślę, że naprawdę polubisz Seaside.

Answer 4

Krótka odpowiedź: nie możesz (na razie) używać Git lub Subversion.

Jeszcze krótsza odpowiedź: nie trzeba go :)

Duża odpowiedź: Zobacz Stephan wyjaśnienie, w jaki Pharo to samo jest tworzony :)) Oczywiście, jeśli jesteś przyzwyczajony do pliku systemy oparte, to będzie dziwne w pierwszej instancji, ale gdy zaczniesz działać, zrozumiesz, że masz wszystkie narzędzia potrzebne do kontroli wersji (monticello - jest to zamiennik Git/Subversion) i do tworzenia złożonych instalacji (metacello - to jest zamiennik rzeczy takich jak maven). Przy niektórych pracach (jak zawsze iz dowolną platformą, którą wybierzesz), możesz skonfigurować własny ciągły serwer integracyjny (jenkins lub hudson lub cokolwiek innego), a wkrótce będziesz pracował w zespole, tak jak w innych środowiskach, ale z jednym dużym plusem: będzie rozwijać Seaside/Smalltalk: P

Answer 5

Rozwój w Smalltalk jest zwykle bardziej produktywny - ale musisz najpierw nauczyć się nowych narzędzi: Monticello/Metacello do pakowania (pomyśl o tym, jak zapisać pakiet w swoim własnym pliku ZIP z mcz rozszerzenie i własny numer wersji przy każdym zatwierdzaniu). Metacello dostarcza informacje, w których pakiety Monticello pasują do siebie i powinny być ładowane, aby zapewnić pełną działającą aplikację (podobną do POM w Maven, ale w konkretnym pliku klasy ConfigurationOfXXX gdzie XXX jest nazwą komponentu). Nie potrzebujesz narzędzi do obsługi wersji innych niż Smalltalk, takich jak subversion, chyba że chcesz zarządzać zasobami zewnętrznymi, takimi jak obrazy lub skrypty bazy danych.

Zobacz także integrację Hudson/Jenking, ponieważ pomoże to również w automatyzacji budowania wizerunku i ciągłej integracji.

Answer 6

Istnieje kilka narzędzi dla Svn/Git, ale IMHO jest o wiele lepiej, aby przejść z przepływem tutaj i używać Monticello, ponieważ Monticello daje bardzo podobne doświadczenie, jak git, ale o wiele prostsze w użyciu i znacznie bardziej zintegrowane z "Droga Smalltalk".

Nie określono, który Smalltalk, ale jeśli zamierzasz używać Pharo, to zdecydowanie Monticello (i gdy komplikuje się - Metacello na górze).

Answer 7

Możesz również zainteresować się Amber.