Контроль версий для Smalltalk / Seaside?

Question

Я в первую очередь разработчик Java EE.Меня попросили изучить возможность использования Smalltalk / Seaside в следующем веб-проекте.Как вы можете себе представить, это привело ко многим интересным вопросам.

Как команда разработчиков реализует контроль версий программного обеспечения и контроль версий в Smalltalk / Seaside.Можете ли вы использовать Subversion или Git?

Насколько я понимаю, Smalltalk использует изображение, а не сохраняет каждый класс в свой собственный файл.Как это влияет на способность управлять редакциями исходного кода, особенно в команде?

Большое спасибо за любые идеи, которые вы можете предоставить!

Answer 1

Настройка для Pharo (и Gemstone )

Каждый разработчик работает в своем собственном образе.Каждое изменение в методе, которое он делает, сохраняется локально в файле изменений.Это позволяет восстанавливать при сбое изображения.Коммиты создаются путем создания файла monticello , содержащего имя пакета, порядковый номер и имя разработчика.Он знает свое происхождение.Этот файл сохраняется на сервере WebDAV .Здесь его подхватывает задача Дженкинса .Это запускает модульные и интеграционные тесты и создает новые образы, поэтому разработчики могут начинать с свежего образа (как минимум) каждый день.Вот некоторые подробности о слиянии с использованием monticello.Состав продукта (структура пакета) представляет собой другой файл monticello, содержащий описание metacello .Это также позволяет разрабатывать на Pharo и развертывать на Gemstone.Время от времени вам нужно добавлять миграции классов.

Для не относящихся к малым разговорам зависимостей и разработки, тестовых приемочных и производственных различий добавьте создание образов виртуальных коробок, используя vagrant , chef-соло (или кукольный , надеюсь, скоро Coral ), veewee .Конечно, они управляются с помощью git.

В дополнение к использованию статических инструментов контроля качества кода ( smallLint , также проверяет различия между диалектами smalltalk), добавьте Moose и создайте свои собственные контекстно-зависимые динамические визуализации проекта (гуманная оценка)

In VisualWorks Smalltalk, локальный разработчик использует STORE с реляционной базой данных (например, PostgreSQL)хранить местные коммиты.Код организован в пакеты пакетов, с пространствами имен.Сценарий репликации используется для копирования локальных версий в центральную базу данных и из нее.Оттуда процесс такой же, как и при настройке Pharo.

[обновление] На Esug2012 Дейл Хенрикс представил работу, позволяющую использовать git и github для управления кодом smalltalk для нескольких диалектов.По сути, была определена файловая структура ( Cypress для Amber, Gemstone, Pharo, Squeak, VisualAge, STIG для VisualWorks) для хранения методов smalltalk в каталогах.В настоящее время это больше направлено на обмен кода между диалектами, чем на замену родному SCM.

Answer 2

Краткий ответ: вы не можете (пока) использовать Git или Subversion.

Еще более короткий ответ: он вам не нужен:)

Большой ответ: См. Объяснение Стефана о том, как создается сам Pharo :)) Конечно, если вы привыкли к файловымВначале это будет странно, но как только вы начнете работать, вы поймете, что у вас есть все инструменты, необходимые для контроля версий (monticello - это замена для Git / Subversion) и для создания сложных установок (metacello- это замена для таких вещей, как Maven).С некоторой работой (как всегда и с любой платформой, которую вы выбираете), вы можете настроить свой собственный сервер непрерывной интеграции (Дженкинс или Хадсон или что-то еще), и вскоре вы будете работать в команде, как в других средах, но с одним большим плюсом:развиваться Приморский / Smalltalk: P

Answer 3

Есть несколько инструментов для Svn / Git, но, имхо, гораздо лучше пойти по ходу и использовать Monticello, потому что Monticello дает вам очень похожий опыт, как и git, но гораздо проще в использовании и гораздо более интегрирован с «Путь по-тихому».

Вы не указали, какой Smalltalk, но если вы собираетесь использовать Pharo, это определенно Монтичелло (а когда все усложняется - Metacello сверху).

Answer 4

Разработка в Smalltalk, как правило, более продуктивна, но сначала вам нужно узнать о новых инструментах: Monticello / Metacello для упаковки (представьте, что вы сохраняете пакет в собственный ZIP-файл с расширением mcz и собственным номером версии каждый раз, когда вы фиксации). Metacello предоставляет информацию, которая соответствует пакетам Monticello и должна быть загружена для обеспечения полноценного рабочего приложения (аналогично POM в Maven, но в определенном файле класса ConfigurationOfXXX, где XXX - имя компонента). Вам не нужны инструменты управления версиями, отличные от Smalltalk, такие как subversion, если вы не хотите управлять внешними ресурсами, такими как изображения или сценарии базы данных.

Также обратите внимание на интеграцию Гудзона / Дженкинга, поскольку это также поможет вам автоматизировать создание изображений и непрерывную интеграцию.

Answer 5

Smalltalk имеет свои собственные системы упаковки / управления версиями, где пакеты исходного кода находятся под контролем, разделены, объединены и т. Д. Какие диалекты Smalltalk вы планируете использовать?В Pharo есть Монтичелло и Метачелло, в Squeak - Монтичелло, в VisualWorks - МАГАЗИН.

Answer 6

Вы также можете быть заинтересованы в Amber .

Answer 7

VA Smalltalk имеет Зависть .

Какой бы Smalltalk вы ни выбрали, я думаю, вам действительно понравится Seaside.