Сегодня я расскажу вам немного о CyanogenMod. Это такая замечательная прошивка, основанная на исходном коде android. Официально разработка идет под вот этот вот список аппаратов, но на деле поддерживаемых девайсов намного больше. А все благодаря ребятам с xda-dev, которые портируют прошивку на свои телефоны.

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

Добрейшего.

Набрёл на неплохой текст от команды Microsoft Team Foundation Server: Branching Guidance
Будущим и нынешним пользователям обозначенной системы предлагается:

1. проникнуться важностью ветвления и слияния изменений для работы больших команд;
2. узнать, какие типы веток бывают и как строить изоляцию работы на их основе;
3. посмотреть на практических примерах как надо правильно отращивать и мёржить изменения.

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

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

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

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

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

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

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

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

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

Disclaimer

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

Вместо предисловия

И снова доброго времени суток!

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

1. Цикл статей по основам Software Configuration Management. О том, что такое СМ, каковы его задачи и за что отвечает в рамках проекта CM-инженер.
2. Software Configuration Management // Конфигурации и baselines. О том, что такое рабочий продукт в терминах SCM, что такое конфигурация, как она стабилизируется, а так же что такое базовые конфигурации — baselines.

В этой заметке речь пойдет о том, что большинство называют bugtracking systems. Мы посмотрим на этот класс задач и инструментов с более обобщенной точки зрения.

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

Ниже речь пойдет о следующих вещах:
— Рабочие продукты и конфигурации;
— Компонентная разработка;
— Продуктовые линейки;
— Стабилизация результатов работы;
— Baselines AKA базовые конфигурации;
— Конфигурации при компонентной разработке;
— Конфигурации при наличии продуктовых линеек.

Пролог

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

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

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