Mercurial (он же Hg) — весьма приятная распределенная система контроля версий (distributed VCS). Среди удобств DVCS вообще и Hg в частности можно особо выделить высокую гибкость. Репозиторий может называться как угодно, копироваться куда угодно, коммититься в продакшн по произвольным цепочкам (скажем, через QA или напрямую) и так далее.

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

Если два репозитория вложить один в другой, Mercurial будет рассматривать их изолированно. Команды, адресуемые внешнему репозиторию, не распространяются на вложенный. Но как же управляться с проектом, если он раздроблен на изолированные фрагменты — этакие пузырьки, один в другом? Или, другими словами, как нам за деревьями (репозиториями) увидеть лес (проект) и работать на его уровне? От мучений нас избавит ForestExtension — расширение для Mercurial. Этот Forest добавляет несколько команд, идентичных базовым, но учитывающих вложенность репозиториев.

Как разрабатывать большое ПО? Ни для кого не секрет, что потребность в разработке больших и сложных программных продуктов была всегда и также всегда была независимой от уровня технологий, существующих на тот или иной момент времени. Но исследуя и анализируя существующие подходы к девелопменту, я так и не смог ответить на самые простые вопросы, связанные с «правильной» разработкой качественных программ. Одним из простейших вопросов, который я перед собой ставил, был вопрос о том, как назначать номера версий выпускаемому программному продукту.

Перевод статьи Эрика Синка (Eric Sink) — DVCS and DAGs (Part 1 and Part 2).

Прим. переводчика: В этой статье я буду ис­поль­зо­вать ори­гиналь­ные анг­ло­языч­ные сокращения DVCS и DAG для обозначения расп­ре­делён­ных систем контроля версий (Distributed Version Control System — DVCS) и нап­равлен­ных ацикличных графов (Directed Acyclic Graph — DAG).

Продуктивность коллектива веб-студии напрямую зависит от удобства среды разработки. У нас сложилась стройная система организации работы с проектами, включающая в себя набор таких неотъемлемых компонентов, как IDE, SCM, PM-система, багтрекер и development-сервер. Этим постом я бы хотел начать цикл статей, посвященных настройке и использованию этих компонентов в нашей студии.

В первой части я расскажу о самом основном — среде разработки (о том, как мы организовали совместный доступ к проектам).

Идеи

1. Среда разработки должна быть единой для всех сайтов.
2. Девелоперы не должны тратить время на настройку каждый своей серверной части.
3. Работает ли над проектом один человек или несколько — контроль версий необходим.
4. Если рабочий каталог (IDE workspace) находится на сервере, то можно поработать и дома, не тратя время на повторную настройку окружения на домашнем десктопе или ноуте.

Пролог

Что такое управление конфигурацией в разработке ПО? Зачем оно нужно? Думаю, немногие способны полностью и внятно ответить на этот вопрос. Большинство обычно вспоминает системы контроля версий, которые сами используют. Кто-то упоминает багтрекинг. Кто-то считает вершиной CM отращивание веток в любимой системе контроля версий. А кто-то вообще уходит в сторону и начинает говорить про ITIL и про то, как он записывает в какую-нибудь базу параметры всего софта, который установлен у него в фирме.

Несколько странно и немного досадно наблюдать за этим. Дело в том, что я проработал в SCM в общем сложности около 5 лет, из них 3 года — интегратором в Motorola, на одном из проектов по разработке софта для сотовых телефонов. По ходу дела прочитал кучу материалов по этой теме и получил большой практический опыт — в том числе по работе с одной из мощнейших систем контроля версий IBM Rational ClearCase (см. linkedin в профиле). В итоге в голове сформировалась некоторая целостная картина того, что же это на самом деле — software configuration management.

И снова здравствуйте.

Продолжаю публиковать цикл статей о SCM — управлении конфигурацией ПО.
3 предыдущие заметки можно прочитать в этом же блоге.

Сегодня расскажу о том, с чем работает большинство читателей — о контроле версий.

Disclaimer

Далее будут описаны основные техники, реализованные в подавляющем большинстве систем контроля версий. Как они реализуются в приложениях, которые использует читатель, оставим на откуп многочисленным руководствам пользователя, how-to, FAQ и прочим документам, коих можно найти без труда. Главное – понять, по каким принципам и зачем оно работает именно так.

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

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

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

Приветствую. Как и обещал — продолжение цикла заметок об управлении конфигурацией ПО, в простонародье называемом Software Configuration Management. Весь цикл можно найти по ссылке на тэг CM. Из ещё неохваченного осталась буквально пара заметок.

Сегодня речь пойдет о довольно спорном и в чём-то провокационном вопросе — распределенных системах контроля версий. Знаю, что подобные системы популярны среди хабравчан, так что заранее готов в обсуждению. Более того — призываю не проходить мимо и высказаться, если есть что сказать по делу.

Прошло много времени, прежде чем я созрел на написание второй части статьи, посвященной управлению конфигурациями. Тому, что это наконец таки свершилось способствует тот факт, что не так давно мне посчастливилось выступать на конференции PHPCONF 2009 8 октября (Web Architect Workshop Day) с мастер-классом «Метод организации репозитория исходного кода». Для выступления были заблаговременно подготовлены презентация, а также текст доклада. Несмотря на отличную организацию мероприятия, для публичного доступа так и не были выложены материалы докладов, входящих в программу конференции. В качестве компенсации я решил таки опубликовать материал, использованный в моем выступлении. Кроме данной статьи, (которая является логическим продолжением предыдущей), посвященной конфигурационному менеджменту, для публичного обозрения доступны слайды презентации.
В данной статье пойдет речь об инструментах, использующихся при управлении конфигурациями. Поэтому в первую очередь хотелось бы заострить внимание на том, как инструменты, использующиеся в разработке могут влиять на процесс создания ПО.

Давайте каждый попробует ответить на вопрос: как установить apache на сервер? Этот вопрос порождает ещё десяток: какая ОС стоит на сервере, какую версию ставить, где лежат конфиги по-умолчанию и т.д. и т.п.

А теперь давайте попробуем ответить на вопрос: как установить apache на 1000 серверов? Тут, при стандартном подходе, вопросов возникнет ровно в 1000 раз больше. Часть из вас наверняка подумали, что можно написать скрипт на shell/perl/python/ruby, который будет обходить все сервера и устанавливать apache, другая часть подумала о distributed shell'ах (PDsh, dsh, etc), кто-то же подумал монтировать rootfs серверов по NFS.

В ряде случаев выше предложенные варианты решений удовлетворительны, но на практике я нигде не видел полностью гомогенных систем (зачастую, внутри компании можно встретить не только разные версии ОС, но и различные дистрибутивы. Также в России/СНГ очень распространена каша из FreeBSD/Linux в ядре проектов), так что вряд ли за адекватное время будет возможно написать скрипт, который установит и настроит apache на зоопарке в 1000 машин под CentOS, Debian, Ubuntu, FreeBSD всевозможных версий.

По моим наблюдениям, очень мало IT подразделений, даже очень крупных компаниий, используют в своей работе SCM (Software Configuration Management). В этом посте я постараюсь описать все преимущества использования Chef в IT инфраструктуре на простых примерах и больших масштабах.

Если же, после столь короткого вступления, вы не прониклись идеей Chef, да и времени читать длинный технический пост у вас нет, то рекомендую вам пролистать до конца и посмотреть как используем Chef мы, Engine Yard, 37signals и подумать, можете ли вы переложить на него часть своей работы.

После недавней вводной публикации о Chef я решил немного больше рассказать о полезных рецептах:

С опозданием от плана на полгода вышел Trac 0.12.

Trac — это интегрированная система управления проектами, включающая в себя систему отслеживания ошибок, вики, инструмент планирования и очень мощный просмотрщик хранилищ систем контроля версий.

В новой версии:

• Локализация интерфеса;
• Поддержка множества хранилищ в одном проекте;
• Расширение вики-синтаксиса, поддержка таблиц, переименование страниц;
• Режим редактирования вики-страниц, в котором область предварительного просмотра расположена бок о бок с редактором и обновляется автоматически;
• Редактирование комментариев с автоматическим предпросмотром по мере ввода;
• Возможность удаления карточек и комментариев (отдельно включается в настройках);
• OR в запросах;
• И множество других интересных изменений.

Скачать, установить или обновить.

Также радует поддержка плагина для Mercurial.

В целом релиз получился очень насыщенным. Тем кто пользуется обновляться обязательно.

цели:
— организация непрерывного внедрение нового функционала проекта
— связанная система исправления багов в процессе поддержки проекта
— повышение качества проекта в целом
— атомарность разработки отдельных частей проекта (модули / функции)

Для достижения описанных выше целей необходимо организовать следующую структуру веток:
release
hotfixes (необязательна)
testing
fixes (необязательна)
default
developers branches (условное название)

HgAssist — repositories are synced!

Пользуясь системой управления кодом Mercurial мы часто сталкивались с тем, что забывали делать push после того, как в локальный репозиторий были сделаны комиты.

Когда различных репозиториев несколько штук, то действительно трудно помнить об их синхронизации и можно легко оставить центральный репозиторий без наших изменений.

Поэтому мы написали HgAssist.

Многие команды, которые используют Subversion для хранения исходных кодов к некоторому моменту начинают задумываться о построении полноценной среды управления жизненным циклом разработки (Application Lifecycle Management). При этом возникают непростые вопросы. В первую очередь это то, как объединить средства контроля версий, управления задачами, багами, артефактами и сборками проекта в единую систему. Путей тут два – либо развивать текущий комплекс, постепенно подключая к нему недостающие компоненты, либо мигрировать на систему, которая все эти компоненты содержит. Для тех команд, которые используют в качестве основного инструмента Visual Studio, подходящим вариантом является Team Foundation Server. Но при этом возникает несколько важных вопросов – как минимизировать время простоя команды, а еще лучше сделать процесс миграции незаметным.

Так уж сложилось, что до недавнего времени все проекты, написанные мною на Java я собирал, кхм, за меня собирал NetBeans. И меня такой расклад вещей вполне устраивал: после сборки всего проекта всё аккуратно складывалось в директорию dist со всеми подвязанными библиотеками, оставалось накидать туда пользовательской документации, необходимых native-библиотек (например от Firebird) и в путь, т.е. всё в архив. Когда то я делал это вручную, потом велосипедом, а потом уже Maven'ом. Под катом находится история о том, как же я пришел в стан maven и что из этого получилось.

Service Control Manager (SCM)

SCM — это сервер, реализованный в Windows, для удаленного управления сервисами (вызовом процедур).

Для того, чтобы запустить драйвер в Windows, ему в соответствие ставится сервис, который обеспечивает управление этим драйвером. Не путать с устройством, которое создает драйвер в системе, через которое происходит обмен сообщениями с драйвером. Это устройство создается уже после старта драйвера, а вот SCM обеспечивает само внесение драйвера в систему. С помощью SCM можно: добавлять, удалять, запускать или останавливать службы.

Постановка задачи

Написать буферный класс позволяющий упростить работу SCM в C#.
Сам внешний вид этого класса можно обознать очень просто:

public ref class ServiceControlManager : public IDisposable
{
public:
	ServiceControlManager(void);
	void AddDriver(String^ ServiceName, String^ BinaryPathName);
	void DeleteDriver(String^ ServiceName);
	void StartDriver(String^ ServiceName);
	void StopDriver(String^ ServiceName);
protected:
	~ServiceControlManager();
	!ServiceControlManager();
private:
	SC_HANDLE SCMHandle;
};

Конструктор, деструктор, финализатор, основные методы, из атрибутов только HANDLE объекта SCM. Из этого следует, что экземпляр объекта этого класса будет содержать в себе созданный объект SCM, а методы упрощают с ним работу. Класс является буферным, и поскольку он реализован в C++/cli он будет автоматически масштабируем для работы в среде .NET, соответственно и в C#.

Здравствуй, мой любознательный %username%!

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

Rebase — один из двух способов объединить изменения, сделанные в одной ветке, с другой веткой. Начинающие и даже опытные пользователи git иногда испытывают нежелание пользоваться ей, так как не видят смысла осваивать еще один способ объединять изменения, когда уже и так прекрасно владеют операцией merge. В этой статье я бы хотел подробно разобрать теорию и практику использования rebase.

Теория

Итак, освежим теоретические знания о том, что же такое rebase. Для начала вкратце — у вас есть две ветки — master и feature, обе локальные, feature была создана от master в состоянии A и содержит в себе коммиты C, D и E. В ветку master после отделения от нее ветки feature был сделан 1 коммит B.

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

Вводная: представьте, что вы некая компания, которая производит планшеты и телефоны — майфуны и майпады. Сами вы сидите в Калифорнии, у вас есть несколько своих заводов на Востоке, плюс вы регулярно заказываете кучу всяких комплектующих у тех поставщиков, от которых это выгоднее везти. И ещё у вас есть своя розничная сеть магазинов, где продаются планшеты и телефоны.

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

Есть три проблемы:

• Логистика у нас настолько сложная и разветвлённая, что сейчас над ней работают десятки людей: кто-то занимается распределением майфунов, кто-то раскидывает по магазинам обложки, а производственники просчитывают оптимальные пути сбора комплектующих на заводах со всего мира.
• При этом хочется сэкономить на логистической схеме: вы подозреваете, что умный анализ всех потоков позволит принять решения, например, о месте открытия нового производства или организации дополнительного склада, что в итоге даст вам выгоду.
• И при этом ваши люди постоянно ошибаются с отправлениями – а хочется сделать так, чтобы ничего и нигде не забывалось, всё работало как часы и товары приходили на точки вовремя. Это тоже экономия, но уже за счёт своевременности поставок и отсутствия ошибок.