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

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. Как следует из названия, описывает, почему же надо придерживаться политики ветвления "одна задача - одна ветка". Предполагаемый уровень читателя - новички в области контроля версий, применяющие простые практики.
Так понравилась, что решил перевести. Думаю, многим покажется интересной, несмотря на то, что объясняются, в общем-то, простые вещи.

Итак, текст.

О надежности систем контроля версий

Добрейшего.

И опять страничка юмора в бложике!

Взято из постоянно читаемого комикса Not Invented Here, очень рекомендую.

Пример выбора иструментов, или Как жить дальше?

Добрейшего.

На своем опыте убеждаюсь, что вопрос выбора инструментария может встать даже в устоявшихся проектах и коллективах. А всё потому, что на основном месте работы сложилась занятная ситуация с организацией и инструментами разработки.
Есть следующие команды разработчиков. Большая команда разработчиков - назовем её Команда Ф (так оригинальнее). Есть маленькая команда разработчиков (Команда Д). И есть я, пусть это будет Командой А (ничего общего с тупым сериалом 80-х).
Есть и другие команды - техподдержка, дизайнеры, верстальщики, менеджеры, редакторы - но они нас не интересуют в разрезе заметки.

Git, Mercurial, Bazaar — работа с SVN и управление патчами

Добрейшего.

Через Хабр набрел на статью Сравнение DVCS - несколько задач. Рассматриваются популярные распределенные open source системы - Git, Hg, Bzr - с точки зрения работы через них с репозиториями SVN. Да, вот такая необычная постановка задачи.

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

Листал подшивки CM Journal

Добрейшего.

Не так давно решил пролистать все прошлые выпуски CM Journal, выпускаемые редколлегией сайта CM Crossroads. Узнать, так сказать, чем дышат корифеи и апологеты современного SCM. Итог - 3 интересные статьи.

В целом я ожидал много интересного. Но, увы, в сборнике за 2 (два) с лишним года ежемесячных выпусков мне лично показались интересными только 3 (три) статьи. Остальные говорили или о вещах очевидных, или нужных, но только тезисно, или о злободневных, но декларативно, без конкретики. Очень много "воды" и рассуждений о космических кораблях на просторах Большого театра. Модное нынче направление agile-разработки точно также очень часто упоминается, но, опять-таки, конкретики очень мало. Периодически встречаются опечатки, сбившиеся буллиты в перечислениях, хромающее оформление - в общем, "написано профессиональными программистами".

Из понравившегося.

Пианист в борделе

Добрейшего.

В пору моей работы SCM-инженером в Мотороле меня периодически спрашивали, кем я работаю. Немедленно вспоминался следующий анекдот.

В школе детей спрашивают - кем работают ваши папы?
Кто-то говорит - бизнесменом, кто-то - военным, кого-то - строителем.
Вовочка: "А у меня папа - пианист в борделе!"
Учительница негодует и требует отца в школу. Тот приходит и выслушивает гневные тирады - "Как вам не стыдно такое ребенку рассказывать!".
На что отвечает: "Понимаете, вообще я разработчик, пишу распределенные вычислительные системы под кластеры, но разве это объяснишь 10-летнему пацану?"

Собственно, SCM-инженер в большой команде - из того же разряда. Слишком долго от начала до конца объяснять, чем же он занимается :)