Как сделать сборку (java) максимально “независимой от CM”?(CM= Менеджер конфигурации)

Question

Я подумывал о том, чтобы сделать одну из сборок проекта, которыми я занимаюсь, настолько "независимой" от меня (CM), насколько это возможно.Под этим я не просто подразумеваю автоматизацию с помощью скриптов / инструментов - хотя это определенно включает в себя.В этом проекте царит большой хаос, и поэтому "полная" автоматизация была бы нереалистичной.

Вот к чему я стремлюсь:

Любой должен быть в состоянии выполнить сборку (с некоторой автоматизацией и небольшим количеством документации / руководств) - например, новичок в CM или даже разработчик без опыта работы в CM.

Мои первые мысли заключаются в том, чтобы достичь этого с помощью:

1. Контроль процесса запроса на сборку (с помощью форм сборки, которые фиксируют ВСЕ детали, необходимые для сборки, чтобы ничто не провалилось сквозь щели только потому, что это у кого-то в голове)

2. Упрощение этапов сборки, чтобы их можно было зафиксировать в простой документации в виде последовательности команд - обученная обезьяна должна уметь работать со сборкой (well..не сыплю оскорблениями, но - вы уловили идею :-) )

3. Полное использование возможностей инструмента (читай ANT, SVN) таким образом, чтобы потенциальные проблемы выявлялись заблаговременно, а также помогали предоставлять более качественные оповещения в случае сбоев / проблем.

4. Иметь свободу заболеть или время от времени брать отпуска без того, чтобы у руководителя проекта случались приступы паники каждый раз, когда я упоминаю пару выходных.:-)

Я был бы рад, если бы у вас были какие-то мысли и идеи, которые помогли бы мне в этом направлении.Спасибо всем!

Answer 1

В Городской код, мы называем это анти-шаблоном "Боб Строитель".Хорошая новость заключается в том, что Боб (вы) хочет выйти из петли.Когда специалист по сборке не может отправиться в отпуск или заболеть без того, чтобы часть процесса не была остановлена, возникает действительно неприемлемая проблема.Если я любитель поспорить, то, когда вы начнете процесс упрощения процесса до уровня "дрессированной обезьяны", вы зададитесь вопросом, зачем вы тратите свое время на эту механическую работу, когда вы умны и действительно могли бы где-то принести пользу.

Симптомы синдрома "Боба-строителя" в нашей книге:

1. Все запросы на сборки или сборки определенного типа проходят через отдельного человека или небольшую команду.
2. Реакция на эти запросы на сборку раздражающе медленная для разработчиков.Если команда сборки на обеде, они ждут часами.
3. Боб, или команда Бобов, тратит значительный процент своего времени на выполнение рутинных заданий.
4. Бобы, уходящие на день домой, на обед, в отпуск или заболевшие, препятствуют способности команды доводить дело до конца.

Мы рассказываем нашим Муравейникпро клиенты должны внедрять все такого рода материалы в свою автоматизацию.Наличие двух типов сборки, которые используют разные машины, разные номера сборки и т.д., Не должно быть проблемой.

Первый шаг - это заглушить процесс.Устраните как можно больше сложностей, чтобы вы могли приступить к процессу "дрессированной обезьяны".Как только у вас появится что-то, приближающееся к этому, заменить обезьяну компьютером довольно просто.

Я бы дал более конкретный совет, но я не думаю, что вы сказали нам, откуда берется сложность, кроме хаоса.Иногда в такой ситуации вам нужно атаковать хаотичные и плохие практики.Вы делаете сборки, которые являются "Этой базовой линией в исходном коде и этими двумя файлами и этими тремя файлами?" Это было бы сложно и, вероятно, потребовало бы CMer в цикле.Найди способ запретить это.Замена этого на "Создайте ветку и внесите определенные изменения в эту ветку" делает построение сборки выполнимым с помощью этой обезьяны.

Вы должны быть в состоянии аргументировать эти изменения как высокий риск.Даже если у вас все хорошо, у вас будут плохие дни, и вы захотите максимально исключить человеческую ошибку из уравнения.В то же время, если вы стремитесь к более быстрому реагированию на запросы разработчиков и самообслуживанию (чего, по-видимому, хотят разработчики и руководство), некоторые вещи необходимо будет сделать автоматизируемыми.

Иметь лучшие формы может быть полезно в промежуточный период, а хорошо использовать свои инструменты - это всегда хорошо, но я бы довольно агрессивно атаковал проблему "дрессированной обезьяны".Все, что не может быть сделано дрессированной обезьяной (или компьютером), должно быть кандидатом на выход из процесса.Как только вы понизите его до статуса "обученная обезьяна", запустите автоматизацию сборки, чтобы ни вам, ни разработчикам не нужно было быть обезьянами.Это меняет вашу роль с "Боб-Строитель" на "Боб - владелец системы сборки".

Answer 2

Упрощение этапов сборки, чтобы их можно было зафиксировать в простой документации в виде последовательности команд - обученная обезьяна должна уметь работать со сборкой (well..не сыплю оскорблениями, но - вы уловили идею :-) )

Если это возможно, то должна быть возможность запустить сборку за один шаг с помощью скрипта (возможно, это будет ant, bash, maven или любой другой скрипт).Это должно быть целью, так что в принципе любой может выполнить сборку.

Answer 3

Целью разработки процесса сборки должно быть следующее:

1. Начните с пустого каталога в любом месте (tabula rasa, если хотите).
2. Убедитесь, что установлен очень небольшой набор базовых инструментов (для меня это обычно Java + Maven + SVN клиент командной строки).
3. Проверьте a одинокий каталог из вашего SVN/CVS/...
4. Запустите одну команду (а это означает что-то, у чего нет 25 параметров)
5. Подождите (возможно, довольно долго)
6. Получите свою полную сборку

Если вы не можете этого сделать, значит, ваш процесс сборки все еще недостаточно хорош.

Если вы считаете, что не можете этого достичь, то подробно опишите, какие действия вам нужно выполнить в дополнение к этому списку, которые невозможно выполнить с помощью машины, полной по Тьюрингу.

Обычно такого пункта не существует.Не хватает только инструментов / ноу-хау / мотивации.Лично я обнаружил, что сделать это проще, чем описывать, почему это не может быть сделано.

Удачи.