Добрейшего.
В предыдущем посте я упоминал Майкрософт и политики управления конфигурациями, которую они использовали для разработки Windows. Нашел презентацию от одного из инженеров, работавшим над Windows 2000 - Марка Луковского - где примерно половина материала касается непосредственно системы контроля версий и обеспечения параллельности разработки. Считаю, познавательный материал. Ниже - сама презентация и некоторые мысли.
Захотите посмотреть на полный экран - жмите Full.
В общем, какие, с моей точки зрения, важные моменты я увидел.
Наследство от Win NT 3.1 досталось веселое - строгая подчиненность; все работают на одной ветке (другие не позволяет система); жесткая связь процесса выпуска билда системы и его тестирования; ломает один разработчик - починки ждут 1400 разработчиков и вся команда из 5000 голов. Надо было что-то делать. В первую очередь - разбивать всё на более мелкие составляющие - более мелкие команды; менять систему контроля версий; автоматизировать отстройку.
В результате взяли SourceDepot (доработанный Perforce) и перекочевали на неё "на живую", по ходу работы. Параллельно работала SLM (предыдущая система контроля версий) и шла миграция на SourceDepot, причем попутно менялась сама структура исходников проекта. Представить только как полторы тысячи человек (постепенно это число выросло до 5100 человек) перетаскивают всю эту уйму кода, попутно жонглируя им в совершенно другие структуры (а число файлов постепенно выросло до 411 тысяч файлов) - жутко интересно становится, во что оно им стало по времени и нервам...
С внедрением новой системы стало возможным вести полноценные ветки - для подпроектов, отдельных компонентов и фич. Это же позволило более гибко подойти к вопросу об отстройке промежуточных результатов - ведь теперь можно было пробовать любые решения у себя на ветках, отстраивать их там и не стопорить работу всей команды. Учитывая, что у каждой команды были свои мощности для отстройки и тестирования, думаю, они все вздохнули с облегчением. Вообще, автоотстройке уделялось много внимания и процесс постепенно отладился до автобилдов дважды в сутки с рассылкой автоуведомлений.
В общем, за 10 лет работы процесс работы изменился полностью, превратившись из поделки на коленках у небольшой команды - в огромный отлаженный механизм.
Народ спорил, что такое же можно было бы сделать с помощью любой распределенной системы. Наверное, не спорю. Не забывайте, что по состоянию на то время из распределенных систем был разве что BitKeeper, да и сама концепция распределенных систем была для знакома лишь гикам-разработчикам Линукса. Да и, судя по всему, им требовалась какая-никакая централизация и разделение труда, ведь команда быстро растет и устраивать хаос на ровном месте руководству совсем бы не захотелось. Как именно работала централизация - опять же, читайте предыдущую статью про применение SourceDepot.
Так что работали с тем что есть и сработали на отлично. И система получилась весьма неплохой, и процесс работы вышел полностью отвечающий всем требованиям. Инструменты - это всего лишь инструменты. Сами по себе они ничего не дадут, нужен мастер для их "оживления". В описанном случае видно, что инструмент не просто подобрали из того, что было, а фактически сделали на заказ, ручной работы получился, заточенный под руку и хват мастера.
Так что грамотные правила совместной работы, поддерживаемые инструментарием - это отличная комбинация.
P.S. И, конечно же, привет противникам ветвления ;)
Комментариев нет:
Отправить комментарий
Примечание. Отправлять комментарии могут только участники этого блога.