Коротко о главном

http://goo.gl/AMY6

A successful Git branching model

Добрейшего.

Я не сторонник распределенных систем контроля версий, однако соглашусь с недавно переведенной статьей о ветвлении: несомненной заслугой  распределенных систем контроля версий является то, что они открыли людям глаза на хорошие практики ветвления и слияния. При всей распространенности того же SVN, в нём ужасно реализованы ветки. Точнее, их и ветками нельзя называть - там, по сути, отращивается новое дерево файлов, мрак в общем, на мой взгляд.

Не удивительно, что стали появляться и вменяемые руководства по практикам ветвления для новоиспеченных лидеров рынка - в первую очередь git и Mercurial. На одно руководство я уже ссылался. Не прошло и года, как я наткнулся на ещё одно руководство: A successful Git branching model.

Личный опыт внедрения Redmine

Добрейшего.

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

В общем, перво-наперво задача стояла поменять систему отслеживания запросов на изменения, или попросту багтрекер. К моменту написания заметки на пробу использовал Jira, подумывал оценить её и предложить соседней команде в качестве альтернативы использовавшегося ими Eventum. Когда стали обсуждать переход в участниками команды, решили посмотреть на прайс Джиры... посмотрели и решили, что Redmine, обладающий тем же функционалом, но за бесплатно, вполне подойдет :) У меня был опыт его настройки и внедрения в процесс, так что переход обещал быть быстрым.

Кто такой релиз-инженер

Добрейшего.

В продолжение вопроса о том, кто такой СМ-инженер.

Анатоликс не так давно вывесил вакансию релиз-инженера для поиска Яндекса . Собственно, по ссылке - пример того, кто такой настоящий release engineer. Практически тем же самым (ну, с поправкой на количество серверов), мы занимались во времена работы с интеграционной команде Моторолы.


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

Кстати, вот обсуждение на RSDN. Для сравнения - обсуждение на sql.ru, прям небо и земля...

Развернуто об одной ветке на каждую задачу

Добрейшего.

Периодически читаю посты из командного блога Plastic SCM - продукта, обзор которого я не так давно делал. Продукт очень интересный, поэтому стараюсь быть в курсе того, что у них происходит.
И вот публикуется очередная статья, называется Branch per task workflow explained. Как следует из названия, описывает, почему же надо придерживаться политики ветвления "одна задача - одна ветка". Предполагаемый уровень читателя - новички в области контроля версий, применяющие простые практики.
Так понравилась, что решил перевести. Думаю, многим покажется интересной, несмотря на то, что объясняются, в общем-то, простые вещи.

Итак, текст.