Тяжелая болезнь не дает мне заниматься общественно полезными делами. Но все-таки я нашел времечко и залил в эту бездонную гуглевскую бочку ещё одну статью на заданную тему. Надеюсь, что админ, который должен настраивать бэкапы этого сервера, компетентен и не позволит пропасть в неизвестности двум килобайтам текста, который дается мне сейчас с большим трудом. Статью про "Хороший тон использования представлений" я решил отложить на следующий раз в связи с вышекуазанным хронофагом, будь он трижды не ладен! Вот так вот, по доброму, без ненормативной лексики, мы переходим к сути этого эссе.
Контейнеры, объекты и элементы, о которых велась речь ранее, в полной мере дают возможность вам отображать части предметной области и организовывать их согласно потребностям вашего проекта. Этих механизмов достаточно, чтобы уверенно ориентироваться в разных версиях вашей программы. Но StarTeam также предоставляет дополнительные инструменты, которые позволяют оперировать такими понятиями, как билд, релиз и версия. Вот некоторые из них:
1) Связи(Links). Свзяи в StarTeam позволяют связывать произвольные объекты между собой. Например, запрос на изменение может быть связан с файлом - патчем, который призван устранить ошибку в программе. Объекты конечной точки связи (у связи имееся две точки – начальная и конечная. В Starteam существует разница между этими точками.) могут быть прикреплены к определенной ревизии объекта, или они могут быть «плавающими», т.е. быть связанными с последней версией объекта.
2) Метки (Labels). Используются для того, чтобы можно было легко сослаться на определенный набор объектов нужной версии. Метка представления (View Label) обычно ссылается на определенную версию всех объектов этого представления, а ревизионные метки (revision label) обычно ссылаются на определенные версии небольшой группы объектов. (Легко представить такую ситуацию: есть стабильная версия приложения, и требуются провести большие изменения. Перед обновлением кода в Starteam можно создать метку, назвав её «Супер-пупер стабильная версия» или «перед сумасшедшими изменениями, выклянченными любимым заказчиком». Теперь, в случае чего, в любое время можно одним мановением руки вернутся к этой проверенной версии, а следовательно - спокойно спать ночами)
3) Содействующие состояния (Promotion states) в StarTeam построены как раз на основе меток представления и поддерживают понятие итерационных билдов, релизов и процессов развертывания. (По сути, содействующее состояние – это ссылка на метку. Процесс применения содействующих состояний можно показать на таком вот простом примере: допустим, у нас есть стабильная версия программы. Мы создаем метку представления и называем её «1.0». Есть также тестовая версия программы – для неё используется метка «1.1». Далее администратор создает два содействующих состояния: «Release» и «Test» и связывает их с первой и второй меткой соответственно. Это нужно для того, чтобы неотокрые пользователи Starteam работали не с конкреноной меткой, а с некоторым абстрактным понятем, характеризующими состояние проекта. Например, исходные файлы стабильной версии программы выгружаются и компилируются автоматическим скриптом, используя содействующее состояние «Release». А группа тестирования продукта выгружает и строит исполняемые файлы, используя состояние «Test». Через некоторое время мы закончили работу над версией «1.1», и эта версия программы стала стабильной, а для новой тестовой версии создается новая метка «1.2 Новогодние задумки». Для работы в новых условиях администратору надо только изменить в соответствующих содействующих состояниях ссылки новые на метки, а конфигурацию автоматического сборщика и группы тестирования менять не надо – они как работали, так и работают с текущими настройками и могут даже ничего не знать о произошедших изменениях)
4) Правила обработки (Process Rules): проект может быть сконфигурирован так, чтобы предписать использование специальных правил, которые определяют, какие действия нужно выполнить перед добавлением нового файла или check-in файла в хранилище Starteam (Для версии 2005 реализована только возможность потребовать связать добавляемый файл с задачей, требованием или CR). Правила обработки удобны для создания ключевых билдов или конфигураций.
1) Связи(Links). Свзяи в StarTeam позволяют связывать произвольные объекты между собой. Например, запрос на изменение может быть связан с файлом - патчем, который призван устранить ошибку в программе. Объекты конечной точки связи (у связи имееся две точки – начальная и конечная. В Starteam существует разница между этими точками.) могут быть прикреплены к определенной ревизии объекта, или они могут быть «плавающими», т.е. быть связанными с последней версией объекта.
2) Метки (Labels). Используются для того, чтобы можно было легко сослаться на определенный набор объектов нужной версии. Метка представления (View Label) обычно ссылается на определенную версию всех объектов этого представления, а ревизионные метки (revision label) обычно ссылаются на определенные версии небольшой группы объектов. (Легко представить такую ситуацию: есть стабильная версия приложения, и требуются провести большие изменения. Перед обновлением кода в Starteam можно создать метку, назвав её «Супер-пупер стабильная версия» или «перед сумасшедшими изменениями, выклянченными любимым заказчиком». Теперь, в случае чего, в любое время можно одним мановением руки вернутся к этой проверенной версии, а следовательно - спокойно спать ночами)
3) Содействующие состояния (Promotion states) в StarTeam построены как раз на основе меток представления и поддерживают понятие итерационных билдов, релизов и процессов развертывания. (По сути, содействующее состояние – это ссылка на метку. Процесс применения содействующих состояний можно показать на таком вот простом примере: допустим, у нас есть стабильная версия программы. Мы создаем метку представления и называем её «1.0». Есть также тестовая версия программы – для неё используется метка «1.1». Далее администратор создает два содействующих состояния: «Release» и «Test» и связывает их с первой и второй меткой соответственно. Это нужно для того, чтобы неотокрые пользователи Starteam работали не с конкреноной меткой, а с некоторым абстрактным понятем, характеризующими состояние проекта. Например, исходные файлы стабильной версии программы выгружаются и компилируются автоматическим скриптом, используя содействующее состояние «Release». А группа тестирования продукта выгружает и строит исполняемые файлы, используя состояние «Test». Через некоторое время мы закончили работу над версией «1.1», и эта версия программы стала стабильной, а для новой тестовой версии создается новая метка «1.2 Новогодние задумки». Для работы в новых условиях администратору надо только изменить в соответствующих содействующих состояниях ссылки новые на метки, а конфигурацию автоматического сборщика и группы тестирования менять не надо – они как работали, так и работают с текущими настройками и могут даже ничего не знать о произошедших изменениях)
4) Правила обработки (Process Rules): проект может быть сконфигурирован так, чтобы предписать использование специальных правил, которые определяют, какие действия нужно выполнить перед добавлением нового файла или check-in файла в хранилище Starteam (Для версии 2005 реализована только возможность потребовать связать добавляемый файл с задачей, требованием или CR). Правила обработки удобны для создания ключевых билдов или конфигураций.
(продолжение следует)
Комментариев нет:
Отправить комментарий