Search
Write a publication
Pull to refresh

Comments 12

НЕ ВЫПУСКАТЬ ДО РАЗГОВОРА с Ильей!!!

Видимо, с Ильёй всё-таки не поговорили.
UFO landed and left these words here
Зачем лишняя сущность, когда просто можно было использовать git с распределением кода по веткам и тестированием коммитов перед merge в master? (а ещё есть и pull request'ы...)
Видимо автору требуется не столько технический, сколько бизнес-процесс, с согласованиями, пересогласованиями, ознакомлением и прочим.
Совершенно верно. CCB нужен для продвижения только тех коммитов, которые соответствуют запланированному набору функций, и отслеживания нежелательных коммитов в данной версии продукта, а также разделения всего продукта на компоненты, ознакомления со всеми изменениями сотрудников, ответственных за данный компонент.
Одно другому не мешает. Речь о том что какие-то изменения, даже правильные и стабильные, просто не нужны в продукте на определенном этапе, особенно близко к завершению. На больших проектах с кодовой базов в миллионы строк, даже при дизайне, близком к идеальному, мелкое изменение порой способно заложить мину замедленного действия под весь проект. Так что практика CCB как раз и призвана подобные вещи отслеживать. Ну а инструмент уже вторичен.
В git подобные вещи первоначально закладывались, т.к. он писался под один крупный проект.
Повторюсь — речь не об инструменте, речь об одной из практик управления проектом.
Все эти практики без третьих колёс в git поддерживаются по дефолту.
В дефолтном гите ревьювер может написать комментарии к ветке/коммиту/файлу/строке в файле?
Что должен сделать инспектор, чтобы гит, поменял статус в баг трекере из SUBMITTED в ACCEPTED?
А сейчас просматриваете уже готовые продукты для решения свои задач?
CCB хорошо решает поставленные ему задачи. Но лучшее – враг хорошего!
Хотелось бы услышать объективное мнение от сообщества разработчиков об инструменте, а в случае очень негативных отзывов – названия других готовых продуктов, поддерживающих аналогичную практику.
Sign up to leave a comment.