Соединяем файлы. С успехом.

Раз пошла такая пьянка, сегодня замечу ещё кое-что про Starteam.

Страшное слово автомёдж (Automerge). Его боятся многие разработчики. Они просто не знают ещё, что на самом-то деле страшно в конце плодотворного рабочего дня вместо чекина нажать чекаут. Но шутки в сторону. Автомедж – весьма полезная и экономящая кучу времени вещь. Не буду разводить много воды, сразу приступим к примеру. Есть представление Beta, олицетворяющее собой бета-версию продукта, и есть, как водится, представление Release – релиз. Допустим, в Beta мы придумали три новых класса и хотим их интегрировать в релиз. Делается это в три счета: Открываем нужное представление, в меню нажимаем View->Compare/merge, в диалоге выбираем проект и его представление, в которое хотим внести изменения. Появится окно, логику работы которого описать в двух словах непросто, но на деле с ним очень легко разобраться. Ctrl+F поможет найти вам различия в представлениях (на рисунке это файл Manual.txt).

Чтобы соединить два файла в один, нужно выбрать в контекстном меню конфликтного элемента пункт Merge Items или Auto-Merge Items (но это только для крепких духом. Шутка. Если Starteam обнаружит, что в файлах есть конфликт, он всё равно переключится в ручной режим). Так как в нашем файле данные только добавились, то Starteam отрапортует, что все соединилось успешно. Если автоматическая склейка не получилась в силу каких-то причин, среда выдаст ещё одно замечательное окно, которое позволит свести два файла воедино без лишних переживаний (обратите внимание на номера строк в соединяемых файлах – это типичный конфликт. Но не надо думать, что Visual megre работает только по номерам строк. Это достаточно продвинутый инструмент для поиска блоков текста в файлах).

И ещё, если вы хотите соединить данные из разных проектов, то вначале придется эти данные поставить в соответствие друг другу командой Reconcile. Собственно, из страшного все. Остальное несущественно и осваивается в рабочем порядке.

Звездная команда (Часть 8). Хороший тон использования представлений на примере небольшой команды.

Теперь давайте на примере рассмотрим реализацию небольшого проекта на Starteam.

Перечислим основные постулаты, которых будем придерживаться при развертывании проекта:
1) Главное представление используется для реализации основной линии проекта;
2) Проект конфигурируется таким образом, чтобы предписать создание запросов на изменение, задач, обсуждений, или требований для каждого "модуля". Понятие "Модуль" определено свободно.
3) Для стандартных билдов используются метки представления (View labels) и, возможно, содействующие состояния (promotion states).

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



Когда необходима модификация ("mod"), разработчик отмечает (check-out) требуемые файлы в основном представлении, блокируя те, которые планирует изменить. После создания локальных изменений рабочего файла, включая и создание любых новых файлов, разработчик выполняет испытания модуля, чтобы быть уверенным, что файлы могут быть использованы другими разработчиками. Когда тестирование закончено, разработчик загружает(Check- in) новые и измененные файлы в БД.
Автоматизированный сценарий (не изображен на рисунке) выполняется периодически и создает новую метку представления. Выгрузка (Check-out) файлов из БД делается по этой метке, чтобы откомпилировать и собрать проект и запустить наборы тестовых программ.
Когда в основном потоке разработки приходит время выпуска приложения, от определенной метки представления (например, "Билд 5.3.142 Кандидат релиз") или от содействующего состояния создается branch-all представление. Такое представление используется как представление для поддержки этого релиза, так как единственные изменения, осуществляемые в этом представлении будут патчами для исправления ошибок. Развитие же системы продолжается в основном представлении.
Если изменение, сделанное для представления поддержки считают актуальным для других выпусков, то оно также объединяется с основным представлением (не изображено на рисунке). Сравнение/объединение представлений для этого обычно не требуется. Вместо этого, объединяются конеретные файлы, так как основное представление продолжает развиваться, в то время как представление поддержки остается относительно постоянным для определенного релиза. Этот процесс повторяется для каждого мажорного релиза. В результате для каждого релиза создается свое представление для поддержки.

Для больших проектов и больших команд используются несколько другие принципы ведения проекта, но это все вы без труда найдете в документации Starteam - было бы желание... шефа.

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

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

Звездная команда (Часть 7). Как следует и как не следует работать с представлениями.

Даже такая простая вещь как молоток может успешно использоваться как для забивания гвоздей, так и для отбивания пальцев. И чем сложнее инструмент, тем больше «степеней свободы» у него имеется. Данная заметка позволит вам использовать представления Starteam более эффективно и, возможно, убережет от ненужных проблем.

Итак, основные пожелания по использованию представлений:

1) Трактуйте представления как потоки для реализации определенного этапа жизненного цикла приложения. Элементы представления могут сильно изменяться или не изменяться вообще в зависимости от назначения этого представления.

2) Используйте главное представление как основу проекта. В нем также следует содержать все компоненты и вспомогательные файлы проекта. В зависимости от вашей модели жизненного цикла и размера вашей группы разработки, изменения в проекте могут быть сделаны разнообразными способами с помощью различных представлений. Однако, все изменения в конечном счете перемещаются в главное представление.

3) Используйте branch-all представления. Это Ваша основная рабочая лошадка. Используйте ссылочные представления для read-only задач, таких как, например, сценарии компиляции и компоновки.

4) Метки представления и содействующие состояния удобны и эффективны. С помощью метки представления вы можете быстро отметить все элементы в представлении, выполнить загрузку отмеченных файлов из БД и корректировать ревизию индивидуальных файлов. Содействующие состояния позволяют вам определять логические состояния жизненного цикла программы, такие как тестовые версии, релиз кандидаты и т.д. На основе метки представления или содействующих состояний также могут быть созданы новые представления.

5) Не используйте глубоко вложенных представлений. Представления необходимы в основном как непосредственные дочерние записи основного представления. Иногда необходимы представления третьего уровня (внуки). Если вы создаете представления глубже третьего уровня, вероятно, вы используете представления не эффективно.

6) Не используйте некоторые типы представлений. Не используйте non-derived представления, "плавающие" представления, или изменяемые ссылочные представления кроме как в случае крайней необходимости и только тогда, когда вы полностью понимаете поведение этих типов представления.

7) Не используйте слишком много представлений. Представления - это "тяжелые" объекты. Их создание из существующего представления может занимать значительное время. Они обычно добавляют тысячи новых дочерних элементов в БД. Нормально использовать до нескольких сотен представлений на одном сервере Starteam.

8) Представления не следует использовать как “личное рабочее пространство” для индивидуальных разработчиков.

(окончание следует)

Звездная команда (Часть 6). Дополнительные инструменты организации работы.

Тяжелая болезнь не дает мне заниматься общественно полезными делами. Но все-таки я нашел времечко и залил в эту бездонную гуглевскую бочку ещё одну статью на заданную тему. Надеюсь, что админ, который должен настраивать бэкапы этого сервера, компетентен и не позволит пропасть в неизвестности двум килобайтам текста, который дается мне сейчас с большим трудом. Статью про "Хороший тон использования представлений" я решил отложить на следующий раз в связи с вышекуазанным хронофагом, будь он трижды не ладен! Вот так вот, по доброму, без ненормативной лексики, мы переходим к сути этого эссе.

Контейнеры, объекты и элементы, о которых велась речь ранее, в полной мере дают возможность вам отображать части предметной области и организовывать их согласно потребностям вашего проекта. Этих механизмов достаточно, чтобы уверенно ориентироваться в разных версиях вашей программы. Но 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). Правила обработки удобны для создания ключевых билдов или конфигураций.

(продолжение следует)

Звездная команда (Часть 5). Объекты и элементы.

Темой данной статьи является на первый взгляд несколько запутанная архитектура отображения объектов Starteam в представления по средствам ассоциативных элементов. Понимание данной темы не всегда доступно с первого раза. Более того, эти нюансы нужны исключительно для тонкой настройки работы Starteam и редко используются в обычной практике. Поэтому, если вы только знакомитесь со Starteam, возможно, эта статья будет для вас лишней. =)

Важно понять, как объекты отображаются с помощью представлений (видов). Каждый объект отображается в некоторый вид с помощью дополнительной сущности, называемой элементом (Item) или, как ещё говорят, членом представления. Когда новый объект, допустим файл, добавляется к представлению, Starteam создает новый объект типа файл с версией 1.0, и это влечет за собой создание нового элемента, который "указывает" на тот файл. Элемент не только определяет, на какой файл ссылаются, но и определяет папку, в которой появится файл. Так, например, если Вы перемещаете файл из одной папки в другую, Вы фактически изменяете элемент - файл, чтобы указать на другой родительский элемент - папку, но сами объекты файл и папка фактически не измененяются. Отношения между элементами и объектами иллюстрированы на следующем рисунке.

В этом примере изображены два представления, указывающих на элемент - корневую папку. Каждый элемент указывает на соответствующий объект, и каждый элемент, отличный от элемента-коренвой папки указывает на родительский элемент-папку, определя тем самым, где располагается этот элемент.
Элемент, созданный от имени нового объекта называют родительским элементом. Дочерний элемент, созданный копированием родительского или дочернего элемента, позволяет отобразить тот же самый объект в другом месте. Дочерний элемент указывает на родительский элемент, с которого он был скопирован. Дочерние элементы создаются в двух случаях:
1) Когда используются дочерние представления(child views): В случае, когда новое представление создано как потомок другого представления, элементы родительского представления копируются, чтобы создать элементы дочернего представления. Сами объекты при этом не копируются – новые дочерние элементы представления просто указывают на те же самые объекты.
2) Когда используются разделяемые ресурсы (Shares): Элемент может быть явно скопирован, создавая "разделяемый" элемент (надо держать Ctrl и тянуть мышкой нужный элемент в StarTeam клиенте). В этом случае, выбранный элемент будет скопирован и будет указывать на тот же самый объект, что и оригинальный элемент.

Основное различие между дочерними представлениями и дочерними разделяемыми элементами - их начальная конфигурация. На поведение объекта частично влияет конфигурация родительского или дочернего элемента, по средствам которого мы имеем возможность управлять этим объектом. Чтобы понимать, как ведут себя родительские и дочерние элементы, необходимо понять разницу между свойствами элемента и свойствами объекта.
Свойства объекта: Большинство свойств, которые Вы видите – имя, кем изменен, версия, данные (для файла), и т.д. – принадлежит объекту. Когда любое из свойств объекта изменяется – создается другая ревизия объекта. Например, если текущая ревизия Запроса об изменении - 1.2, и свойство «Ответственный» изменено, модифицированный объект типа «Запрос об изменении» будет сохранен с ревизией 1.3. Если в новой версии файла текущая ревизия 1.4.1.2, то следующая будет соответственно - 1.4.1.3.

Свойства элемента: Элемент обладает свойствами, которые определяют, на какой объект этот элемент ссылается, папку, в которой он должен отображаться, и как должны обрабатываться изменения объекта через элемент. Большинство свойств элемента, например, родительское представление и родительская папка управляется StarTeam неявно на основании действий клиента. Однако, существует три ключевых свойства элемента, которые непосредственно затрагивают свойства объекта, на который ссылается элемент:
1) Код объекта (Object ID): Это свойство определяет ветвь объекта, на которую ссылается элемент. Каждый новый объект получает уникальный Код объекта, и его номер ревизии начинается с 1.0. Номер ревизии объекта увеличивается каждый раз, когда обновляется состояние объекта (1.1, 1.2, и т.д.), но код объекта при этом остается неизменным. Следовательно, код объекта, на который ссылается элемент, указывает на целую ветвь объекта и возможно на конкретную ревизию. Когда же объект ветвится, создается новый объект с новым кодом объекта, и номер его ревизии расширяется, чтобы отразить точку ответвления (например, 1.2.1.0). Элемент ссылается на новую ветвь, обновляя код объекта, на который он указывает.
2) Конфигурация поведения элемента (Behavior Configuration): Это свойство определяет, является ли элемент «плавающим» или привязан к определенному моменту времени. Когда поведение элемента определено, как плавающее, элемент указывает на последнюю ревизию ветви объекта, на который ссылается этот элемент. Когда поведение привязано к конкретному моменту времени, элемент ссылаестся на ревизию объекта, которая был актуальным на то время.
3) Автоматическое ветвление при изменении (Branch-on-change): Это свойство действительно только для дочернего элемента, ссылающегося на файл или «запрос на изменение». Оно определяет, что случается при изменении объекта через элемент. Если это свойство установлено в True, Starteam при любой модификации заставляет начинать новую ветвь объекта. Например, если файл загружается в БД (check in) через элемент, и текущая ревизия равна 1.2, автоматически создается новая ветка 1.2.1.0. Когда это свойство установлено в False – это означает, что, или основной объект уже ветвился через этот элемент, или изменение через элемент оперирует тем же самым объектом что и родительский элемент, или этот элемент только для чтения (заморожен).

Важно отметь, что элементы дочернего представления – это автоматически разделяемые ресурсы, которые созданы и управляются путем манипулирования видами, к которым они принадлежат. Следовательно, вы можете сосредотачиваться на управлении непосредственно представлением, не волнуясь о дочерних элементах и механизмах их работы. Однако, если вы создаете разделяемые ресурсы в ручную (через пользовательский интерфейс или команды SDK), необходимо уделить больше внимания свойствам элемента, чтобы понять, как изменения отразатся на других элементах в том же самом разделяемом (общем) дереве. Например, операции над иерархиями разделяемых элементов могут быть достаточно сложными, когда удаляется родительский элемент и поведение промежуточного элемента изменяется. По этим причинам, разделяемые ресурсы должны использоваться с большой осторожностью и только в том случае, когда у вас есть четкое понимание происходящего.

(продолжение следует...)

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

Звездная команда (Часть 4). Понимание представлений.

Сегодня я подробнее расскажу о представлениях (View), которые реализованы в Starteam. Но прежде я хотел бы сделать несколько замечаний про терминологию, которая используется в статье. Во многих системах контроля версий для обозначения копии файла, полученного в результате изменения оригинала используется слово "Версия" (Version). Собственно, отсюда и возникло название таких систем. И Starteam в этом случае не исключение, только версии файла в Starteam называются Revision (что тоже, в общем-то, интуитивно понятно). Кроме простой версионности в Starteam реализовано так называемое ветвление (Branching), которое позволяет рассматривать версии файлов в рамках некого дерева изменений, имея несколько актуальных версий изменяемого элемента (файла, требования и т.п.) на разных ветках этого дерева. Поэтому полный номер версии элемента определяется атрибутом Branch revision, который представляет собой композицию номеров версий файла и ветки. Т.о. когда в статье идет речь про ветвление, то это автоматически подразумевает и версионность элемента.

Когда Вы создаете проект, Вы также создаете начальное или корневое представление этого проекта. В процессе работы над проектом также может быть создано несколько представлений дополнительно. Зачем они нужны? Представления позволяют реализовать очень важную функциональность сервера Starteam – отображать только определенные элементы, входящие в его состав. Причем, критерием отбора могут являтся не только обычные атрибуты элемента, вроде имени и типа, но и дата создания и изменения, версия элемента и т.д. Другими словами, Вы можете конфигурировать представление так, чтобы показать элементы, существовавшие раньше или позже определенного события, на конкретный момент времени, базирующиеся на специальной метке или находящиеся в некотором состоянии. В зависимости от своего назначения можно классифицировать представления по нескольким типам:

1) Представления, динамически отображающие изменения исходного кода и документов в вашем проекте (Dynamic view). Заданное по умолчанию корневое представление относится как раз к этой категории. Оно позволяет вам видеть все файлы и другие элементы проекта «как есть» на текущий момент времени. Представление этого типа отображается, когда Вы выбираете в меню View > Select Configuration > Current Configuration.
2) Изменяемое представление – ссылка (Reference view). Под ссылкой в данном случае следует понимать ссылку на подмножество элементов, найденных в первоначальном представлении. Такое представление часто содержит только элементы, представляющие интерес для определенной группы разработчиков. Любое изменение, сделанное в представлении этого типа изменяет тот же самый элемент в первоначальном представлении. Это происходит потому, что представление содержит ссылки к элементам в первоначальном представлении и не ветвится (см. ниже), когда происходят изменения.
3) Неизменяемое представление-ссылка (RO reference view). Оно основано на определенном состоянии первоначального представления. Такое представление-ссылка создается обычно для удобства поиска конкретных ревизий элементов, используемых в определенных релизах программы. Оно может быть "плавающим" или жестко привязан к определенной дате. Представления этого типа используются в основном для того, чтобы можно было легко восстановить старые версии программы.
4) Представления, разрешающее выполнять ветвление элементов (Branch all view. Также часто их называют версионными). Ветвящиеся представления можно использовать, чтобы изменить элементы, найденные в определенном представлении, не затрагивая эти элементы в других представлениях. Таким образом, мы можем создать несколько ветвящихся представлений в одном проекте и работать над разными версиями программы параллельно, не вызывая конфликтов. Поэтому, ветвящееся представление должно использовать рабочую папку, отличную от рабочей папки ее родительского представления. Использование той же самой рабочей папки для обеих представлений не только запутывает, но и может создать серьезные проблемы. Например, изменения в файлах одного представления могут быть затерты, когда Вы выгружаете файлы из БД от другого представления. Эта происходит потому, что два этих файла имеют одинаковые названия и рабочую папку. Или же состояние файла на клиенте может быть определено неправильно и ввести пользователя в заблуждение. Например, StarTeam может сообщить о состоянии файла в одном представлении как "Неизвестное", "Устаревшее" и т.д., когда действительное состояние файла "Отсутствует", и файл от другого представления с тем же самым названием находится в рабочей папке. Следует отметить, что благодаря своим своствам ветвящиеся представляния - самые востребованные производные представления в Starteam. Обычно, разработчики используют исключительно их.
5) Неветвящееся представление (Branch None view). Этот тип представления, как и ветвящееся представление, основывается на некотором родительском представлении. Как следует из его названия – элементы данного представления не ветвятся при их изменении.
6) Непроизводное представление (Non-derived view). Это самостоятельное представление, которое не наследуется от какого-либо другого представления. Соответственно, оно по умолчанию создается пустым и все элементы в него добавляются по желанию пользователя.

Теперь давайте подробнее рассмотрим наиболее интересные и полезные ветвящиеся представления. Ветвящееся представление - представление, которое разрешает папкам, и другим элементам в представлении отделиться от соответствующих элементов в родителе и, начиная с этого момента, стать изменяемой копией родителя. Ветвление применяется только к папкам, файлам, и запросам на изменение. При этом можно настроить представление так, чтобы определенные его элементы не ветвились. Требования, задачи и обсуждения не ветвятся никогда. Изменения таких элементов можно осуществить в представлении, в котором они были созданы, в представлении, в которое они были перемещены или расшарены, или в "плавающем" дочернем представлении, предназначенном только для чтения. Новые ревизии таких элементов могут быть рассмотрены в любом "плавающем" дочернем представлении.
Пока элемент не ветвится, соответствующие элементы в обоих представлениях остаются идентичными. После того, как пользователь изменил элемент, появляется новая ветвь или, как ещё говорят, версия этого элемента, и они больше не являются идентичными. При этом номер ревизии элемента указывает на новую ветвь. Единственный способ снова сделать элементы идентичными состоит в том, чтобы вручную объединить их, сравнивая и объединяя представления с помощью команды Compare/merge views. После того, как происходит ветвление, StarTeam больше не посылает и не применяет обновления от соответствующего элемента в родительском представлении. Из соображений безопасности, удаления, сделанные в родительском представлении не размножаются к дочернему представлению и наоборот. Если Вы хотите удалить папку или элемент изо всех связанных представлений, Вы должны удалить их из каждого представления в отдельности.
Ветвящиеся представления предназначены для различных целей:
1) Выполнение разнообразных потребностей в зависимости от ваших задач. Например, можно создать исправленную версию или заказную версию вашей программы, ответвленную от предшествующего коммерческого релиза.
2) Начало разработки следующего релиза вашей программы, используя некоторые или все файлы от предыдущего выпуска.

3) Хранение части вашего проекта приватно, пока она полностью не закончена и не протестирована. Когда потребуется, Вы можете объединить ваши изменения с основным проектом.

(продолжение следует)

Звездная команда (Часть 3). Логическая конфигурация проекта

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

Итак:
1) Каждый Starteam сервер может содержать несколько проектов:
2) Каждый проект имеет главное представление (View) и любое количество дочерних представлений: 3) Каждое представление (и главное, и дочерние) ассоциировано с некоторой StarTeam-папкой, называемой главной (root folder): 4) Каждая главная StarTeam-папка может содержать иерархию дочерних папок, называемых StarTeam-каталогом (иерархией папок):
5) Когда администратор создает новый проект, автоматически создаются главный вид и главная папка проекта. Они будут иметь такое же имя, как и имя проекта, например «GreatApp» (позднее администратор может поменять эти названия): Рассмотрим пример, показанный на следующем рисунке.

В нем конфигурация сервера содержит два проекта: Dev1, чье главное представление имеет 2 дочерних представления, и Doc1, главное представление которого имеет единственное дочернее представление, которое в свою очередь тоже имеет дочернее представление. Как видно из рисунка, развитие проектов сохранено в консолидированном репозитарии – базе данных и файловом архиве. В любое время пользователь Starteam может выбрать нужное ему представление и начать с ним работу. Однако, чтобы понять все нюансы работы с представлениями, следует подробнее разобраться, что же представляет собой это представление. Об этом мы поговорим очень скоро, как только я сформулирую свои мысли в виде буквенно-цифровых последовательностей, называемых в простонародии текстом.

(продолжение следует...)

Звездная команда (Часть 2). Объекты Starteam

Объекты – это основные информационные единицы в пределах сервера Starteam. Все объекты являются версионными. Это означает, что существует возможность обратиться к отдельным ревизиям объекта, отметить отдельные версии, создать ответвления (про ветвление будет подробнее рассказано в следующей части) и т.д. Содержимое объекта хранится как ряд свойств, каждое из которых имеет имя и значение. Для каждого объекта также Вы можете добавить произвольные свойства. StarTeam поддерживает следующие типы объектов:

1. Файлы(Files): Как во всех SCM системах, файлы - самый важный тип объекта в StarTeam. Свойства файла содержат метаданные, такие как атрибуты безопасности, история изменения, ссылка на лицо, изменившее файл и т.д. Понятно, что файлы и сами по себе содержат двоичные или текстовые данные и сохраняются в хранилище(Vault) на сервере. Файлы являются версионными и могут ветвиться в отдельные версионные деревья. Файлы поддерживают и возможность создания связей(линков) и прикрепления меток.



2. Запросы об изменении(Change Requests): StarTeam поддерживает систему отслеживания ошибок и изменений с помощью объектов типа Change Requests. Подобно файлам, CR может быть версионной, связанной, помеченной метками, ветвиться и т.д. CR обычно используется, чтобы представить дискретные запросы типа сообщений об ошибке, некорректной, неправильной работе программы, а также для внесения изменений в её работу.


3. Задачи(Tasks): В StarTeam задачи похожи на этапы планирования работы, используемые в системах руководства проектоми типа Microsoft ® Project (Фактически, задачи StarTeam могут быть синхронизированы с задачами Microsoft Project). Задача обычно представляет один конкретный шаг в решении комплексного задания и может быть назначена нескольким сотрудникам. Задача может быть разделена на подзадачи и отслежена через лог записей о её выполнении. Задачи также являются версионными и могут быть промаркированы, связаны, и т.д, однако они не могут ветвиться в версионные деревья подобно файлам и запросам об изменени.


4. Темы(Topic): тема - подобие сообщения в телеконференции, которое может быть послано одним пользователем, ответ написан другим и т.д. Цепь сообщений на данную тему создает “дерево обсуждений”, которое может быть присоединено к файлу, запросу об изменении, или другому объекту. Подобно задачам, темы являются версионными, но не не могут ветвиться в версионные деревья.


5. Требования(Requirements): StarTeam поддерживает упрощенную систему требований, которая может быть использована для документирования на ранних стадиях разработки жизненного цикла проекта. Требования могут быть созданы и реализованы непосредственно в StarTeam, или они могут быть импортированы и синхронизированы с объектами от других систем управления требованиями типа CaliberRM ™. Требования являются версионными, но не не могут ветвиться в версионные деревья.


6. Папки(Folders): Каждое представление(вид) имеет корневую(главную) папку, которая обычно содержит дерево подпапок. Папка может содержать объекты любого типа, включая другие папки. Хотя папки – это по сути дела "контейнеры", они имеют свойства и являются версионными. Следовательно они также являются объектами StarTeam, и, подобно файлам и запросам об изменении, могут ветвиться в версионные деревья. Обратите внимание, что логический путь папки определяется на основании пути его родительских папок. Однако, путь к соответствующей рабочей директории, в котором сохранены файлы на клиенте, может не соответствовать логическому пути. Т.о. рабочая директория может быть переопределена на клиенте. Это очень удобно, так как у разных разработчиков системы настроены по разному. Более того, могут использоваться разные ОС, например Windows и Linux.

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

Звездная команда (Часть 1)

Ну что ж, как и обещал, выкладываю первую часть статьи про Borland Starteam. В ней кратенько рассказывается об основных возможностях продукта. Тон получился немного помпезный, но это потому, что в качестве шпаргалки для написания статьи были использованы презентационные материалы, а они, знаете ли, грешат глянцем =). Starteam (как и CaliberRM) изначально был разработан компанией Starbase, а в начале 2003 года куплен Borland и интегрирован в линейку их ALM решений. Сейчас на сайте Borland доступен для скачивания Starteam 2008 с триальной серверной лицензией на 30 дней. Клиентские лицензии в данном случае не требуются. Далее я буду приводить актуальные на сегодняшний день куски статьи вперемешку со своими комментариями.

Приложения масштаба предприятия, безусловно, нуждаются в управлении процессом их создания и эксплуатации. Очень важно, чтобы правильно осуществлялись проектирование приложения и управление проектом, управление изменениями, а также, чтобы производительность труда участников проекта была максимальной. Borland StarTeam - система конфигурирования и координации действий всех участников проекта - позволяет достичь этих целей. StarTeam представляет собой средство управления конфигурациями и изменениями на основе системы контроля версий. Продукт поддерживает несколько клиентских интерфейсов (в частности, Windows- и Web-интерфейс (раньше была отдельная версия Starteam для веба, теперь же это просто довесок для выноса интерфейса в веб. Только под IIS)), утилиту командной строки для пакетных задач), имеет мультиплатформенного Java клиента, может интегрироваться с оболочкой Windows Explorer (это так называемый StarDisk – средство, представляющее сервер Starteam в виде ещё одного диска в ОС. Средство, безусловно, полезное для менеджеров, далеких от разработки ПО, но имеющих документы в репозитарии Starteam), Microsoft Project и некоторыми другими сервисами, позволяет организовывать дискуссии между членами проекта, имеет встроенную систему планирования и управления проектом, организацией рабочего времени участников проекта, беэгтрекинга и управления требованиями. На базе StarTeam можно создавать и свои собственные решения для конфигурационного управления — для этой цели Borland предоставляет API для Java, COM и Microsoft .NET Framework.

Все данные о проекте (исходные тексты, модели, документы, рисунки, графики) хранятся в едином репозитарии. Все, что относится к одному и тому же проекту (документы, модели, код), хранится на одном и том же сервере, где можно осуществлять управление этими активами и организовывать документооборот. Репозитарий доступен по протоколу TCP/IP с поддержкой криптования для удаленных соединений и управляется с помощью сервера. Данные, относящиеся к проекту, хранятся в серверной СУБД (Microsoft SQL Server/Oracle) и в специальном файловом хранилище (хочу отметить, что версии файлов лежат на диске, а другие артефакты - в БД). Т.о. распределенным командам нужен лишь доступ в Интернет.
Borland StarTeam интегрируется с системой Borland CaliberRM – специализированной системой управления требованиями, обеспечивая совместное использование средств поиска и анализа информации (Search Server и Datamart соответственно), что позволяет искать и анализировать информацию во множестве распределённых хранилищ (Это для суровых разработчиков. Небольшой команде в небольшом зеленом проекте хватает за глаза и за уши встроенной в Starteam системы требований). За счет этого можно улучшить предсказуемость, контролируемость и качество процесса разработки программных продуктов. Вторым важным продуктом, с которым интегрируется StarTeam, является Borland Gauntlet – среда для непрерывной автоматической сборки и тестирования.
С целью уменьшения нагрузки на системных администраторов крупных организаций, использующих Windows Server 2000/2003, система StarTeam обеспечивает поддержку аутентификации пользователей средствами Microsoft Active Directory по протоколу LDAP (в том числе и через SSL). Благодаря этому сисадмины могут централизованно контролировать различные аспекты аутентификации пользователей на сразу на нескольких серверах StarTeam (В целом штука, безусловно, удобная, так как экономит время админу. Но вот чтобы настроить SSL, надо прикрутить центр сертификации).
Для распределения и балансировки нагрузки, повышения отказоустойчивости, а также увеличения быстродействия системы в целом в сетевой архитектуре Starteam предусмотрена возможность создания кеширующих серверов (Startem MPX server), поддерживающих мультикаст.
Чтобы получить более конкретное представление о Starteam, можно посмотреть ролики, выложенные на официальном сайте.
На этом введение заканчивается, а на следующей неделе я постараюсь подготовить и опубликовать статью про логическую структуру сервера.

Стартуем!

Коллеги! На днях хочу выложить для всеобщего ознакомления свою давнишнюю статью про идеологию Starteam версии 2005R2, которую я написал по материалам из статей о продукте и его документации. Статья была написана для внутреннего использования, поэтому её нужно вначале подрихтовать и убрать лишние неологизмы =). Сейчас уже появился Starteam 2008, и конечно, многое изменилось, но основы и идеи, заложенные в предыдущих версиях, актуальны и сейчас. Но прежде я хотел бы поговорить про несколько странное отношение к системам контроля версий со стороны Borland.

Как-то на одной из презентаций 2007-ой версии Delphi я задал вопрос Кириллу Ранневу о том, куда делся интегрированный Starteam – клиент, который был в D2006, и почему исчезли любые упоминания о Starteam из Delphi. Ответ был его достаточно интересным. Дело в том, что Borland и CodeGear договорились о том, что CodeGear будет SCM нейтральным, а Borland – IDE нейтральным. Причин этому может быть много, но мне теребит мозг только одна - топ - менеджеры Borland так хотели дистанцироваться от своего убыточного софтверного подразделения, что даже отказались от дополнительных продаж в общем-то хорошей SCM системы через своего партнера. Видимо, желание продать неприбыльный актив было столь сильным, что такие нюансы даже не брали в расчет. Сейчас же, когда Borland второй год подряд терпит убытки, а CodeGear приносит прибыль, эта стратегия могла бы измениться. Ведь достойного покупателя CodeGear так и не нашли, и расставаться с компанией, приносящей реальный доход, теперь, похоже, уже никто не собирается. Однако ж, заглядывая в обновленный роадмап, мы не видим никаких упоминаний про интеграцию со Starteam. Удивительное дело, но эти хитрые «договоренности» сыграли плохую шутку сразу со всеми заинтересованными сторонами. Во первых страдают продажи Starteam, которые могли бы быть основаны на бесплатной рекламе со стороны IDE, во вторых – страдает имидж IDE, которая опять не имеет готового и полновесного решения, в третьих – страдают разработчики, которым предоставлена мнимая свобода выбора, а по сути дела – тыкание пользователя лицом в веб для поиска, установки и тестирования подходящего решения самостоятельно.
А ведь интегрированный клиент Starteam появился впервые в ещё D2005. Позднее он был дописан и доработан в D2006 и начисто пропал из D2007. Его нет нигде, ни в официальном вебе, ни в хелпе и даже на партнерском DVD. Вот насколько мощно CodeGear соблюдает ранее достигнутые договоренности. Но это ладно, удивляет другое. На самом сайте Starteam мы можем найти интеграции и к Эклипсу, и SCC и даже к VS! Пользователи же «родных» средств разработки посланы взад к своему дистрибутиву, в котором эту интеграцию днем с огнем не сыщешь. Все, сушите весла, круг замкнулся. Вот такой вот хитрый бизнес…

Знающие люди утверждают, что можно использовать пакет starteam-extensions.jar из дистрибутива D2006, но сама по себе интеграция – не самоцель. Если уж быть до конца честным, лично я не использовал её в своих проектах, довольствуясь стандартным клиентом Starteam, поскольку встроенное в IDE решение было урезанным и не понимало самой вкусности Starteam, а именно багтрекинга и простой, но достаточно эффективной для небольших проектов системы управления требованиями. Но! Как можно представить себе современного разработчика ПО, не обеспеченного системой контроля версий? Это же как надо себя не любить, чтобы отказываться от такого простого и эффективного механизма управления своей работой, способного сэкономить много времени и сил! А ведь многие себя не любят, потому что:
1) Считают использование SCM неоправданно дорогим и сложным.
2) Не видят существенной необходимости в этом.
3) Используют альтернативные пути в виде подпорок из батников и разных других допотопных возможностей ОС.
4) Просто ленятся и т.п.

Вот типичный пример - History Tab – ещё одна красивая подпорка, которая реализует версионность файлов, достаточную, чтобы вскрикнуть: «Ой, что-то здесь было до того, как я выделил текст и нажал энтер!». Безусловно, вещь полезная для тех, кто ещё не научился настраивать бэкап. Но как с помощью неё параллельно делать разные релизы, выпускать для них одинаковые патчи, вести исследовательскую разработку и одновременное тестирование пререлиза, да и ещё много чего другого – не написано ни в одном хелпе. А именно это повседневно нужно коммерческому разработчику ПО.

Самым правильным, на мой взгляд, было бы предложить интегрированное или легко настраиваемое решение, полностью поддерживаемое IDE. Так, чтобы поставил Delphi и опа, вот тебе современный, нужный и настроенный сервис, дорогой ты наш разлюбимый разработчик. Для этого следует поставлять урезанный StarTeam на MSDE c преконфигурённой БД на диске вместе с Delphi. Лицензия должна быть, как у BlackFishSQL, т.е. например 1-2 разработчика – бесплатно, все что больше – платите деньги. И самое важное – подробная и внятная инструкция о том, зачем все это нужно, как это использовать и какие преимущества в работе это дает. Я думаю, эффект будет потрясающим. Потому что слабыми местом Delphi всегда было и остается отсутствие комплексной методологии разработки ПО. А если хочется претендовать на что-то большее десятого места, надо этим делом активно заниматься. Управление жизненным циклом ПО – достаточно сложный и многогранный процесс. Starteam – это не просто система контроля версий, это гораздо большее. Starteam охватывает очень объемную и важную часть жизненного цикла ПО. Грамотное использование таких решений сильно изменит результаты нашей с вами работы. Осталось только донести это в полной мере до всех разработчиков.