Теперь давайте на примере рассмотрим реализацию небольшого проекта на Starteam.
Перечислим основные постулаты, которых будем придерживаться при развертывании проекта:
1) Главное представление используется для реализации основной линии проекта;
2) Проект конфигурируется таким образом, чтобы предписать создание запросов на изменение, задач, обсуждений, или требований для каждого "модуля". Понятие "Модуль" определено свободно.
3) Для стандартных билдов используются метки представления (View labels) и, возможно, содействующие состояния (promotion states).
Для небольших групп разработчиков и/или краткосрочных проектов можно непосредственно использовать основное представление. Дочерние представления создаются, когда выпускается очередной релиз. Впоследствии такое представление используется для обслуживания этого релиза.
Когда необходима модификация ("mod"), разработчик отмечает (check-out) требуемые файлы в основном представлении, блокируя те, которые планирует изменить. После создания локальных изменений рабочего файла, включая и создание любых новых файлов, разработчик выполняет испытания модуля, чтобы быть уверенным, что файлы могут быть использованы другими разработчиками. Когда тестирование закончено, разработчик загружает(Check- in) новые и измененные файлы в БД.
Автоматизированный сценарий (не изображен на рисунке) выполняется периодически и создает новую метку представления. Выгрузка (Check-out) файлов из БД делается по этой метке, чтобы откомпилировать и собрать проект и запустить наборы тестовых программ.
Когда в основном потоке разработки приходит время выпуска приложения, от определенной метки представления (например, "Билд 5.3.142 Кандидат релиз") или от содействующего состояния создается branch-all представление. Такое представление используется как представление для поддержки этого релиза, так как единственные изменения, осуществляемые в этом представлении будут патчами для исправления ошибок. Развитие же системы продолжается в основном представлении.
Если изменение, сделанное для представления поддержки считают актуальным для других выпусков, то оно также объединяется с основным представлением (не изображено на рисунке). Сравнение/объединение представлений для этого обычно не требуется. Вместо этого, объединяются конеретные файлы, так как основное представление продолжает развиваться, в то время как представление поддержки остается относительно постоянным для определенного релиза. Этот процесс повторяется для каждого мажорного релиза. В результате для каждого релиза создается свое представление для поддержки.
1) Главное представление используется для реализации основной линии проекта;
2) Проект конфигурируется таким образом, чтобы предписать создание запросов на изменение, задач, обсуждений, или требований для каждого "модуля". Понятие "Модуль" определено свободно.
3) Для стандартных билдов используются метки представления (View labels) и, возможно, содействующие состояния (promotion states).
Для небольших групп разработчиков и/или краткосрочных проектов можно непосредственно использовать основное представление. Дочерние представления создаются, когда выпускается очередной релиз. Впоследствии такое представление используется для обслуживания этого релиза.
Когда необходима модификация ("mod"), разработчик отмечает (check-out) требуемые файлы в основном представлении, блокируя те, которые планирует изменить. После создания локальных изменений рабочего файла, включая и создание любых новых файлов, разработчик выполняет испытания модуля, чтобы быть уверенным, что файлы могут быть использованы другими разработчиками. Когда тестирование закончено, разработчик загружает(Check- in) новые и измененные файлы в БД.
Автоматизированный сценарий (не изображен на рисунке) выполняется периодически и создает новую метку представления. Выгрузка (Check-out) файлов из БД делается по этой метке, чтобы откомпилировать и собрать проект и запустить наборы тестовых программ.
Когда в основном потоке разработки приходит время выпуска приложения, от определенной метки представления (например, "Билд 5.3.142 Кандидат релиз") или от содействующего состояния создается branch-all представление. Такое представление используется как представление для поддержки этого релиза, так как единственные изменения, осуществляемые в этом представлении будут патчами для исправления ошибок. Развитие же системы продолжается в основном представлении.
Если изменение, сделанное для представления поддержки считают актуальным для других выпусков, то оно также объединяется с основным представлением (не изображено на рисунке). Сравнение/объединение представлений для этого обычно не требуется. Вместо этого, объединяются конеретные файлы, так как основное представление продолжает развиваться, в то время как представление поддержки остается относительно постоянным для определенного релиза. Этот процесс повторяется для каждого мажорного релиза. В результате для каждого релиза создается свое представление для поддержки.
Для больших проектов и больших команд используются несколько другие принципы ведения проекта, но это все вы без труда найдете в документации Starteam - было бы желание... шефа.
На этой радостной ноте я заканчиваю целенаправленное промывание мозгов аудитории всяким пропеиетарным софтом, как пишут некоторые читатели. Надеюсь, эти статьи были полезны русскоязычной аудитории и смогли хоть чуть-чуть прикрыть ту астрономическую пустоту, которая существует в рунете на тему Starteam.
PS. Возможно, я буду периодически публиковать посты на животрепещущие темы. Вот, например, про мёрдж(merge) народ интересуется. Вроде бы простая вещь, а ставит в тупик. Наверное, это какой-то психологический блок?
Комментариев нет:
Отправить комментарий