19 Май 2008 г.

Звездная команда (Часть 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) Хранение части вашего проекта приватно, пока она полностью не закончена и не протестирована. Когда потребуется, Вы можете объединить ваши изменения с основным проектом.
(продолжение следует)

14 Май 2008 г.

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

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

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

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


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

8 Май 2008 г.

Продалися =)

То, о чем так долго говорили большевики, свершилось! А я уж, грешным делом, думал, что идея продавать софтверный бизнес оставила Borland. Многочисленные блоги пестрят сообщениями о том, как это круто. Наверное, так оно и есть. Ценник, правда, сбили на 70 мультов. Но, видимо, для Borland и это хорошо. То, что мирового лидера с многолетней историей в области разработки языков программирования, компиляторов и IDE покупает фирма, делающая утилитки для баз данных о чем - то да говорит. Воистину, мир меняется... и мы вместе с ним.
Ну, как говорится, на новом месте - приснись жених невесте =) Пожелаем удачи CodeGear в новой итерации.

5 Май 2008 г.

Звездная команда (Часть 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.

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

29 Апрель 2008 г.

Звездная команда (Часть 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, можно посмотреть ролики, выложенные на официальном сайте.
На этом введение заканчивается, а на следующей неделе я постараюсь подготовить и опубликовать статью про логическую структуру сервера.