Впечатления от работы с Perforce

Добрейшего.

Как уже писал чуть ранее, я по роду деятельности после смены места работы активно осваиваю новое пианино - Perforce. Часто его сокращённо называют P4.

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

Общие основы

Perforce - типичная централизованная система контроля версий. Есть сервер, который хранит историю изменений подконтрольных сущностей в репозиториях, которые называются depot. Читается как "дипоу", но вообще - просто депо, типа как трамвайное. Клиент, подключаясь к серверу, берет нужную часть сущностей к себе на локальную машину. С этого момента программа-клиент П4 создает т.н. workspace, т.е. рабочее пространство.

Второй раз в ту же реку

Добрейшего.

Как-то за суетой забыл совсем - не так давно я вернулся на предыдущее место работы. Я теперь снова - СМ-инженер. Снова большая корпорация, снова embedded-системы, снова контрактор. Всё как я люблю, в общем. :) Как поется в шлягере гражданина Бадди Гая: "Back to the same old place..."

Основной инструмент теперь - Perforce, а также JIRA, не считая ещё нескольких инструментов. В ближайшее время будет пост про личные впечатления от Перфорса. Откровений, шокирующих подробностей и скриншотов не ждите, ибо NDA никто не отменял. Следите за RSS-лентой, что ещё сказать.

P.S. Теперь, спустя 2 года после заведения блога с записками отставного сиэмщика, впору его как-нибудь переименовать. Но не стану. Меня вот уже и в поиске по этому позывному находят.

Как закрыть задачу в Redmine

Добрейшего.

Ко мне в бложик часто заходят люди по запросам, связанным с закрытием задачи в Рэдмайне. Им в Redmine надо отметить задачу, как выполненную. Видимо, при всей навороченности этой системы, простейшие операции по началу вызывают недоумение. Хотя всё довольно просто и проистекает из идеологии всей системы. Если вы прочитали предыдущие заметки про Redmine, всё должно быть понятно. Но читали их не все (хотя и стоило бы).

Чтоб, как говорится, два раза не вставать - пишу здесь отдельным постом.

Version Control by Example - свежая книжка про контроль версий

 Добрейшего!

Рад сообщить, что вышла книга Version Control by Example (Управление версиями в примерах). Поскольку я пристально слежу за книгами по SCM, появление новых трудов всегда интересно.

Автор книги - Eric Sink (Эрик Синк), человек и пароход, который живет именно системами контроля версий и другими девелоперскими инструментами уже не один десяток лет. Сейчас он вместе с командой создает Veracity, распределенную систему контроля версий.

Текст выложен в виде HTML и PDF, в скором времени будут доступны бумажные копии и версия для Kindle.

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

Что внутри?

Контроль версий и SCM в Google

Добрейшего.

Давно ищу разную информацию, касающуюся SCM в Google. Всегда ведь интересно знать, как работают крупные команды. Были разрозненные данные, и вот не так давно появился повод подытожить то, что известно. Нашелся хороший человек, который там работает, он не смог дать подробную инфу в силу NDA (что вполне понятно и ожидаемо), однако дал подсказки для раскопок общедоступных данных, за что ему спасибо.

Итак, Гугл использует Perforce. Использует практически на всех внутренних проектах. Есть сведения, что в Youtube его создатели использовали Subversion до покупки Гуглом, но наверняка сейчас их перевели на общую платформу.
Для "наружного применения" компания выдаёт все популярные open source системы. В первую очередь это git - через него идёт предоставление исходников платформы Android. Ну а Google Code предоставляет централизованный канонический Subversion и распределённые Mercurial и git (из DVCS сначала выбирали между Hg и git).

Над Perforce располагается широкая прослойка из инструментов, заточенных под работу именно на гугловыми проектами. Вплоть до того, что командой для работы с системой является не "p4", а "g4". Многие  костыли или workarounds, сделанные из-за недостатка функционала, до сих пор работают, несмотря на то, что в самом Перфорсе это уже давно реализовано. Работает старый принцип "работает - не трогай", ведь переделывать инфраструктуру - дело непростое, и зачастую очень богатое на ошибки. Так что после выхода очередной версии P4 её сначала разворачивают на отдельном оборудовании, накатывают сверху все внутренние тулзы, а уж потом, когда всё настроится и заработает, выкатывают это всем остальным.

Сам Perforce работает на системе серверов в режиме 24/7. Оно и понятно, над исходниками проектов работают круглые сутки со всех точек мира. И конечно, его сопровождением занимается выделенная команда инженеров.

Работа ведется без использования веток. Уж не знаю, чем это вызвано - сложностями работы с Перфорсом или другими соображениями - однако оно вот так. Для того, чтобы на транке не появлялись глючные изменения, их необходимо проверять перед тем, как помещать под контроль версий. Долгое время это делалось посредством обмена email-ами и работой через NFS, где расшаривалось рабочее пространство всех пользователей. Потом в 2006 году в компанию пришёл Гвидо ван Россум, создатель языка Python, и сделал систему ревью кода под названием Mondrian. Она позволяет по-прежнему инспектировать изменения до их помещения под контроль версий, но сейчас до коммита вся информация о дельте и комментариях к ней лежит в BigTable (гугловая система ранения). Конечно, удобный веб-интерфейс (Python + JavaScript) сильно упрощает работу, но вот вводить лишнюю сущность для хранения просто потому, что не принято класть изменения на ветки - по меньшей мере странно. Но - им виднее.

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

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

Данные брались из разных материалов, однако основой служат 2 презентации:

• Perforce Users Conference 2010: Developing and Maintaining an Ongoing Strategic Perforce Plan at Google by Geoff Mendal.
• Google Tech Talk 2006: Mondrian Code Review On The Web by Guido Van Rossum.

Кстати, ван Россум сделал из Mondrian отдельное приложение, которые можно взгромоздить поверх Subversion и Google App Engine, называется Rietveld.

Если есть кому что добавить - велкам.

P.S. Для сравнения можно прочитать Немного об SCM в Microsoft и Windows. A Software Engineering Odyssey.

Git в картинках на RSDN

Добрейшего.

Постоянные читатели бложика знают мой скепсис по поводу распределённых систем контроля версий вообще и git в частности. Однако нет-нет, да и проскакивают ссылки, которые просто необходимо утащить в нору сохранить в бложике, чтоб не потерялись. Может кому и пригодится.

Сегодня увидел как раз такую - Git в картинках за авторством Игоря Ткачёва, одного из родоначальников и апологетов сообщества RSDN. Название говорит само за себя - объясняется на картинках, как работать с git через git extentions (оконную надстройку над гитом). Объяснение простое и доходчивое, даже я понял что к чему.

В общем, кто давно хотел подружится с git, но боялся ч0рной командной строки и непонятного английского - это для вас.

10 заповедей хорошего контроля версий

Добрейшего.

Подкинули ссылку на хорошую статью из серии "10 тут-написать-самое-важное". Не смог пройти мимо, т.к. речь - о контроле версий! Называется The 10 commandments of good source control management, или "10 заповедей хорошего контроля версий".

Надо бы её перевести, но пока - перечень Важных Вещей:

1. Если используете VSS - бросьте сейчас же. Прям щас!
2. Если что-то не лежит под контролем версий - этого не существует.
3. Делайте коммиты раньше, чаще и не откладывая.
4. Всегда проверяйте изменения перед коммитом.
5. Помните про психопата с топором перед написанием комментариев.
6. Делайте коммиты сами, не перекладывая на других.
7. Версионности БД избежать не получится.
8. Результаты компиляции не кладутся под контроль версий.
9. Никому не интересны ваши личные настройки.
10. Зависимости надо тоже пристроить.

Как-то так. Просто и понятно. Да ещё и написано с юмором, так что рекомендую.

gihub для совместной работы студентов

Добрейшего!

На Хабре опубликовали интересную заметку - Системы управления версиями как инструмент совместной работы студентов. Ещё один интересный пример использования гитхаба не по прямому назначению :) про другой я недавно писал.

Мне, как преподавателю, решение представляется интересным. Повторю здесь то, что написал в комментариях.


Положительные стороны:
- Централизованное хранилище заданий и результатов. Во многих ВУЗах этого до сих пор нет, а тут - всё под рукой. И не будет типичных проблем накануне сессии из серии "у меня вчера вылетел жесткий диск, что смог, то восстановил, поставьте-хотя-бы-тройку!!!" :)
- Обучение системам контроля версий и багтрекингу. Очень правильно.
- Практика командного взаимодействия. Сначала - между преподом и студентом, потом обязательно начинается работа внутри группы. К тому же многие учебные программы имеют курсовые или лабораторные, прямо предназначенные для коллективной работы.

Отрицательные стороны:
- Необходимость наличия интернета. Да, для многих ВУЗов это до сих пор проблема. Кроме того, есть компьютерные классы, где выход в интернет запрещён или невозможен по техническим причинам.
- Привязка с конкретному инструменту. git и те тулзы, которые доступны на гитхабе - на них свет клином не сошелся. Есть, к примеру, ещё и централизованные VCS, они всё ещё имеют немалое право на существование, особенно коммерческие решения. В общем, получится очень однобоко, а это не есть правильно с точки зрения учебного процесса.
- Работа на стороннем сервисе. Пользователь не контролирует данные, находящиеся на сервисе. Но поскольку данные эти - не несут коммерческой инфы и их утрата не окажет большого влияния на учебу в целом (есть локальные копии), то минус это небольшой.
- Нет гарантии, что гитхаб не изменит свою политику и не ограничит подобные варианты использования.

А вообще - интересно.

Узелок на память: upgrade Mercurial 1.8 для Ubuntu 10.04

Добрейшего.

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

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

Проблема. С Убунтой 10.04 (на мой новый ноут встала только она, 10.10 залазить не хотела) идет Ртутный версии то ли 1.5, то ли 1.6. Я же использовал к тому времени 1.8 и, как выяснилось, старые версии с репами от более новых версий работать отказываются. Убунтовый тул для апгрейда показывал, что в Убунтовых репозиториях доступна только старая версия.

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

> sudo add-apt-repository ppa:mercurial-ppa/releases
> sudo apt-get update
> sudo apt-get install mercurial

Проверяем результат с помощью

> hg --version


Кому надо ещё проапгрейдить TortoiseHg - в статье и про это есть.

Пример описания процесса создания релизов

Добрейшего!

Не так давно (ну хорошо, почти год назад) я решил сформулировать для себя задачи по улучшению инфраструктуры разработки. Проще говоря - надо было уже начать что-то менять в SCM-процессе, и не только в нём.

Упоминавшаяся там команда Ф - достаточно обособленная, но самая крупная, и задачи решает самые разнообразные. Так вот, один из разработчиков нашел время и описал процесс построения билдов и всего, что с этим связано. Фактически, описан процесс выпуска релизов от  получения исходников до начала развёртывания. Применяется много практик из continuous integration, но ими не ограничивается, а сам процесс описывается для Java.

Рекомендую ознакомиться для общего развития. Даже если ваш процесс отличается или вы только собираетесь что-то внедрять, заметка и названия тулов дадут направление, куда смотреть.