Конфигурационный менеджмент (часть 2, обзор инструментов)

[Aquary]

Спасибо за продолжение темы SCM, радует, что она по-прежнему интересна прогрессивной общественности :)
Пользуясь случаем, пиарю свой цикл статей, где даются общие основы CM:

habrahabr.ru/blogs/pm/67751/ — Общее введение
habrahabr.ru/blogs/pm/67839/ — Конфигурации и baselines
habrahabr.ru/blogs/pm/68357/ — Багтрекинг
habrahabr.ru/blogs/pm/68932/ — Контроль версий
habrahabr.ru/blogs/pm/69666/ — Метрики и документация
habrahabr.ru/blogs/pm/72370/ — Распределенный контроль версий

Думаю, оба цикла статей неплохо дополнят друг друга.

[crazyprog]

Вот техническое описание CI для PHP.

[Aquary]

Читал, хорошая заметка, спасибо.

[necromant2005]

Много текста, ни о чем. Прописные истины алитые соусом наукообразия.

[altern]

А что бы вы хотели чтобы было в подобного рода статье?

Между прочим, я рад что для вас всё изложенное просто и очевидно, так как, подозреваю, что не все могут этим похвастаться. Чтобы не оставлять вас абсолютно разочарованным после прочтения, предлагаю ознакомиться с диаграммой: bit.ly/34yQZx. Если у вас получится разобраться, и, более того, вндерить у себя в проекте, то я вас смогу искренне поздравить как состоявшегося scm-гуру. Эта диаграмма — конечный пункт моих попыток описать (это одновременно еще и содержание следующих статей) что такое scm и как можно улучшить существующее положение вещей.

[necromant2005]

А вот эта диаграмма — хорошо, даже очень хорошо. Учитывает все возможные случаи. Для поддержки проекта и последущей интеграции и поддержки.
Правда, имхо, сложнова-то выглядит. И это же еще не все. Надо же еще установить правила, не тольк как разбивать на ревизии, но и как и когда внисить изменения в транк. Иначе это похоже на паралельную разработку множества версий 1, 2, 3 когда-то имевшие общих предков. Версии должны заканчиватся, если появилась версия 2, то в этом момент разраотка версии 1 — прекращается и там исправляются только баги — все.

[altern]

То что вы описали — учитывается. Просто на диаграмме это не изображено. Диаграмма — самый сложный случай, когда все таки нужно поддерживать несколько версий. Банальный пример — open-source библиотеки и фреймворки. Например CakePHP работает как под PHP4, так и под PHP5 — нужно поддерживать обе версии. Плюс вышел PHP5.3 — вполне логично начать экспериментальную разработку с поддержкой новой версии. Итого — как минимум 3 параллельных ветки, ориентированных только на платформу. А ведь еще могут быть вариации самого фреймворка. Так что случаи с окончанием разработки в ветке версии после ее окончания — это не единственный случай, хотя и очень распространенный.

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

[altern]

Вы не поверите, но суть в этом собственно и была — поверхностно описать процессы, входящие в область интересов управления конфигурациями

[altern]

Спасибо, исправил

[mac2000]

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

[necromant2005]

Тут guides.rubyonrails.org/migrations.html :)

[altern]

1. www.ddengine.org/ — storage engine для MySQL, умеющий отслеживать изменения данных
2. Как уже сказал товарищ necromant2005, в RoR есть migrations
3. Если нужно migrations для php, то есть портированные: code.google.com/p/mysql-php-migrations/

[necromant2005]

Есть еще, правда поддержка только Mysql
code.google.com/p/zrails/wiki/MigrationExample

[mou]

Issue Tracking неправильно перевели. Сами же дали ссылку на википедию. А почитать забыли.
Если говорить о иерархии то Artifact Tracking -> Issue Tracking -> Bug Tracking. Баг трекер — частный случай Issue tracker.

[altern]

«контроль постановки задач» — это неправильно? буду рад если вы приведете пример более употребляемого словосочетания. искал искал — не нашел

ну и вроде как я не отождествляю bug tracking и issue tracking, а наоборот — разграничиваю. кстати, по тем же причинам, на которые вы указали: баг трекер — частный случай

[mou]

система отслеживания дефектов.

[altern]

я имел в виду issue tracking. как насчет присутствия enhancement в issue tracking system, в этом случае она все еще «система отслеживания дефектов»?
употребление «баг-трекер» для описания bug-tracker'ов мне кажется вполне допустимым :)

[mou]

Система отслеживания проблем | инцидентов | дефектов | запросов. Нужное подчеркнуть. Самое главное из всех слов «отслеживания», все остальное тонкости.

[altern]

Вообще, говоря о «контроле постановки задач», я имею в виду не конкретную систему(-ы), а деятельность (или процесс).

[mou]

Я понимаю, что вы имеете ввиду. Но еще раз акцентирую внимание, что системы нацелены на отслеживание (можно сказать сопровождение по жизненому циклу) неких артефактов. А есть ли в этом цикле процесс постановки или нет — это уже дело десятое.

[altern]

слово «отслеживание» менее употребимо (ну не звучит и всё тут) в русском языке чем «контроль», да и «контроль» смысл передает лучше.

[mou]

Ну тогда сравниет два серпа

[mou]

yandex.ru/yandsearch?text=системы+контроля+постановки+задач&lr=1
yandex.ru/yandsearch?text=система+отслеживания+запросов&lr=1