Здравствуйте, Aquary, Вы писали:
A>Хммм.... По твоему, это плохо? Есть релизная ветка, есть десятки разработчиков и под сотню изменений... как, по-твоему, обойтись без выденной команды или хотя бы человека, который бы брал на себя интеграцию?
Я не говорю, что это обязательно плохо, проекты бывают разные. Но для меня такой подход это показатель серьезных проблем с организацией кода. Один разработчик никогда не работает над всем проектом целиком. Почти всегда можно разбить проект на несколько независимых модулей с собственной нумерацией версий, независимой сборкой и независимым тестированием. Модули могут взаимодействовать между собой только по явно специфицированным интерфейсам, которые, конечно, придется проверять при тестировании. По тому же принципу можно разбить десятки разработчиков на группы, тогда их коммиты будут вызывать конфликты только внутри группы, а внутри небольшой группы конфликт легко может разрешить сам разработчик. Короче, групповое владение кодом. Никакой общей релизной ветки для всего продукта вообще не потребуется. Для релиза достаточно вытащить стабилизированные версии модулей, собрать в кучу и отдать на тестирование.
Здравствуйте, Miroff, Вы писали:
M>Здравствуйте, Aquary, Вы писали:
A>>Хммм.... По твоему, это плохо? Есть релизная ветка, есть десятки разработчиков и под сотню изменений... как, по-твоему, обойтись без выденной команды или хотя бы человека, который бы брал на себя интеграцию?
M>Я не говорю, что это обязательно плохо, проекты бывают разные. Но для меня такой подход это показатель серьезных проблем с организацией кода.
По-моему, нельзя судить об организации кода, ни разу его не видев.
M>Один разработчик никогда не работает над всем проектом целиком. Почти всегда можно разбить проект на несколько независимых модулей с собственной нумерацией версий, независимой сборкой и независимым тестированием. Модули могут взаимодействовать между собой только по явно специфицированным интерфейсам, которые, конечно, придется проверять при тестировании. По тому же принципу можно разбить десятки разработчиков на группы, тогда их коммиты будут вызывать конфликты только внутри группы, а внутри небольшой группы конфликт легко может разрешить сам разработчик. Короче, групповое владение кодом.
Не поверишь — но именно так и было сделано. Много компонент в составе большого продукта. Продукт — сотовый телефон. Компоненты — программные слои или же классы приложений. Так вот десятки разработчиков были именно в отдельных компонентах, которые, конечно, были разделены на подкомпоненты с группами поменьше. И даже внутри группы часто работа шла над одними и тем же файлами. Да, было групповое владение кодом, однако каждый сидел на своей ветке для отдельный изменений по отдельным запросам. А интеграторы компоненты собирали изменения вместе от всех групп и из этого делали что-то, что можно было целиком отдать тестерам на прогон комплексного тестирования.
M> Никакой общей релизной ветки для всего продукта вообще не потребуется. Для релиза достаточно вытащить стабилизированные версии модулей, собрать в кучу и отдать на тестирование.
Как обычно, сознание изменено терминологией и принципами SVN... Мы использовали правильную систему контроля версий, где у каждого элемента — своё дерево версий (так сделано практически везде, кроме SVN). И релизная ветка — это ветка, созданная для каждого элемента автоматом.
Думаю, больше рассказывать не буду, а то много получится, тема не про это
В общем, пора, наверное, уже написать мне очередную статью по configuration management и рассказать как наша команда далала подобные вещи.
Здравствуйте, Qbit86, Вы писали: Q>Потому что SVN-сервер не пропустит! Он потребует сделать предварительный апдейт. И при этом придётся сделать merge и resolve conflicts. И всё это — «наживую», в «красной» рабочей папке, малейшая ошибка чревата безвозвратной потерей локальных изменений.
Вот честно. У меня ни разу не было проблем при апдейте.
Q>квази-транк со смягчёнными (в любой степени) требованиями.
Мы пробовали. В итоге в мегастабильном транке необходимость отпала, и квазитранк стал обычным транком.
Здравствуйте, Mr.Cat, Вы писали:
Q>>Потому что SVN-сервер не пропустит! Он потребует сделать предварительный апдейт. И при этом придётся сделать merge и resolve conflicts. И всё это — «наживую», в «красной» рабочей папке, малейшая ошибка чревата безвозвратной потерей локальных изменений. MC>Вот честно. У меня ни разу не было проблем при апдейте.
С этим впору поздравлять!
Q>>квази-транк со смягчёнными (в любой степени) требованиями. MC>Мы пробовали. В итоге в мегастабильном транке необходимость отпала, и квазитранк стал обычным транком.
Здравствуйте, Qbit86, Вы писали: Q>>>квази-транк со смягчёнными (в любой степени) требованиями. MC>>Мы пробовали. В итоге в мегастабильном транке необходимость отпала, и квазитранк стал обычным транком. Q>У вас есть выделенная билд-машина?
Да.
Здравствуйте, Mr.Cat, Вы писали:
MC>>>Мы пробовали. В итоге в мегастабильном транке необходимость отпала, и квазитранк стал обычным транком. Q>>У вас есть выделенная билд-машина? MC>Да.
Что происходит, когда код в рабочей копии билд-машины не собирается? Состояние «последняя сборка провалена» как-то выделено? Разработчики об этом оповещаются автоматически, или должны ручками опрашивать состояние?
Здравствуйте, Qbit86, Вы писали:
Q>Это не управляемость. Это лишние, внешние, искусственные ограничения — учитывать ещё и гранулярность коммитов.
Это именно управляемость. Чем меньше задача, там легче ее оценить, запланировать, сделать и протестировать. В случае достаточно мелкой гранулярности (<8 часов на задачу) конфликтов при коммите вообще не возникает. Если же задача занимает неделю, то ее трудно точно оценить, трудно синхронизировать с другими изменениями и уж почти наверняка при коммите по этой задаче возникнут конфликты. А спрогнозировать возникновение конфликтов и затраты на их разрешение практически нереально.
Q>Да, если не сложно. Это, наверное, ортогонально топику, но тем не менее.
Здравствуйте, Miroff, Вы писали:
Q>>Это не управляемость. Это лишние, внешние, искусственные ограничения — учитывать ещё и гранулярность коммитов.
M>Это именно управляемость. Чем меньше задача, там легче ее оценить, запланировать, сделать и протестировать. В случае достаточно мелкой гранулярности (<8 часов на задачу) конфликтов при коммите вообще не возникает.
Так ведь если задача занимает 8 часов, я обязательно захочу закоммитить промежуточные результаты раз пять, пока её сделаю. Создать точки отката перед рисковыми рефакторингами, etc.
Здравствуйте, Qbit86, Вы писали: Q>Состояние «последняя сборка провалена» как-то выделено? Разработчики об этом оповещаются автоматически, или должны ручками опрашивать состояние?
Да, разработчики оповещаются, но проблем с поломанным транком обычно не бывает (а если бывают, то обычно обнаруживаются работающими в транке коллегами при апдейте, а не билд-системой). Но у нас просто размер проекта позволяет перед коммитом убедиться, что все билдится (а билдить все равно приходится — например, чтобы проверить, что баг, над которым идет работа, больше не воспроизводится).
Здравствуйте, Mr.Cat, Вы писали:
Q>>Состояние «последняя сборка провалена» как-то выделено? Разработчики об этом оповещаются автоматически, или должны ручками опрашивать состояние? MC>Да, разработчики оповещаются, но проблем с поломанным транком обычно не бывает (а если бывают, то обычно обнаруживаются работающими в транке коллегами при апдейте, а не билд-системой).
Вот. Мы тоже работали по схеме «проблемы обнаруживаются при апдейте другим разработчиком» (или даже: «Вась, можешь выгрузить и проверить, всё ли собирается?»). Но это контрпродуктивно и опасно (скажем, если на момент обнаружения поломки автора уже нет в офисе, etc). Как только вы придёте к автоматической проверке состояния «билд сломан» (т.е. «должен быть как можно скорее починен, для восстановления инварианта»), это и будет означать «стабильный транк». Пусть проверок вначале мало (только собираемость), но это уже концептуально правильное начало.
MC>Но у нас просто размер проекта позволяет перед коммитом убедиться, что все билдится
А статус файлов «Added» тоже проверяете глазами? Или, скажем, проверяете, что все публичные методы задокментированы? Etc, etc, etc, таких проверок могут быть десятки. Даже при образцовой добросовестности можно что-нибудь упустить.
Здравствуйте, Qbit86, Вы писали: Q>Как только вы придёте к автоматической проверке состояния «билд сломан» (т.е. «должен быть как можно скорее починен, для восстановления инварианта»), это и будет означать «стабильный транк». Пусть проверок вначале мало (только собираемость), но это уже концептуально правильное начало.
По идее, конечно, при коммите надо на сервере делать билд (возможно, проводить какой-то минимальный набор тестов) и сообщать авторам последних изменений, если билд сломался. Но лень, честно говоря.
Q>А статус файлов «Added» тоже проверяете глазами?
Ага.
Q>Или, скажем, проверяете, что все публичные методы задокментированы? Etc, etc, etc, таких проверок могут быть десятки. Даже при образцовой добросовестности можно что-нибудь упустить.
А это и не надо проверять постоянно. Ну что-то там не задокументировано. Ну пара тестов устарела и свалилась. Обычно это не мешает править критичные баги, обмениваться изменениями с другими разработчиками и отдавать версию на ручное тестирование. Эти вещи можно исправлять по ходу работы над другими задачами и по мере возникновения свободного времени. У задач может быть различный приоритет, и я против того, чтобы устраивать бюрократию вокруг задач с заведомо не самым высоким.
Здравствуйте, Mr.Cat, Вы писали:
MC>По идее, конечно, при коммите надо на сервере делать билд (возможно, проводить какой-то минимальный набор тестов) и сообщать авторам последних изменений, если билд сломался. Но лень, честно говоря.
Конечно, лень! Если ты программист, то лень входит в перечень твоих должностных обязанностей. Билд на сервере (где окружение «чище», чем у разработчика; скажем, нет Visual Studio) должна делать автоматика, ей не лень.
Q>>А статус файлов «Added» тоже проверяете глазами? MC>Ага.
Но ведь если что-то упустишь, то фидбэк будет отложенным (до момента, когда ты уже почти ушёл из офиса домой). Свитч контекста опять же, всё такое.
Q>>Или, скажем, проверяете, что все публичные методы задокментированы? Etc, etc, etc, таких проверок могут быть десятки. Даже при образцовой добросовестности можно что-нибудь упустить.
MC>А это и не надо проверять постоянно. Ну что-то там не задокументировано. Ну пара тестов устарела и свалилась. Обычно это не мешает править критичные баги, обмениваться изменениями с другими разработчиками и отдавать версию на ручное тестирование. Эти вещи можно исправлять по ходу работы над другими задачами и по мере возникновения свободного времени. У задач может быть различный приоритет, и я против того, чтобы устраивать бюрократию вокруг задач с заведомо не самым высоким.
Это не бюрократия. Это assistance. Это дисциплина. Это чистоплотность. Как чистить зубы, делать зарядку, обращать внимание на ворнинги компилятора.
Здравствуйте, Qbit86, Вы писали: Q>Это не бюрократия. Это assistance. Это дисциплина. Это чистоплотность. Как чистить зубы, делать зарядку, обращать внимание на ворнинги компилятора.
Либо мы друг друга недопонимаем, либо это та дисциплина, которая вместе с бондажом, садо и мазо. Давай представим гипотетическую ситуацию. В транке есть критичный баг (допустим, он мешает тестировщикам что-нить там тестировать). Девелопер его зафиксил, но не задокументировал свой код, и в процессе фикса стала невалидной пара тестов. Ты считаешь, что прежде, чем закоммитить фикс, девелопер должен удовлетворить все твои проверки?
Здравствуйте, Mr.Cat, Вы писали:
MC>Либо мы друг друга недопонимаем, либо это та дисциплина, которая вместе с бондажом, садо и мазо.
Не, садо-мазо начнётся, если я ещё пару гардов к CI-серверу прикручу :)
MC>Давай представим гипотетическую ситуацию. В транке есть критичный баг (допустим, он мешает тестировщикам что-нить там тестировать). Девелопер его зафиксил, но не задокументировал свой код, и в процессе фикса стала невалидной пара тестов. Ты считаешь, что прежде, чем закоммитить фикс, девелопер должен удовлетворить все твои проверки?
Можно временно отключить какое-то подмножество проверок от какого-то конкретного проекта. В любом случае, поведением по умолчанию будет проверка всеми разумными средствами, и лишь в каких-то редких случаях нужно делать исключения. А не наоборот. Как у безопасников: вайт-листы (запрещать всем, кроме некоторых допущенных) предпочтительнее блэк-листов (разрешать всем, кроме некоторых забаненных).
Здравствуйте, Qbit86, Вы писали:
MC>>Давай представим гипотетическую ситуацию. В транке есть критичный баг (допустим, он мешает тестировщикам что-нить там тестировать). Девелопер его зафиксил, но не задокументировал свой код, и в процессе фикса стала невалидной пара тестов. Ты считаешь, что прежде, чем закоммитить фикс, девелопер должен удовлетворить все твои проверки?
Q>Можно временно отключить какое-то подмножество проверок от какого-то конкретного проекта. В любом случае, поведением по умолчанию будет проверка всеми разумными средствами, и лишь в каких-то редких случаях нужно делать исключения. А не наоборот. Как у безопасников: вайт-листы (запрещать всем, кроме некоторых допущенных) предпочтительнее блэк-листов (разрешать всем, кроме некоторых забаненных).
Не надо все делить на "черное" и "белое". В некоторых случаях непрохождение некоторых проверок не является критичным (например надо релизнуть в срок). Тем не менее надо постоянно стремиться чтобы все проверки проходились.
Здравствуйте, gandjustas, Вы писали:
Q>>Можно временно отключить какое-то подмножество проверок от какого-то конкретного проекта. В любом случае, поведением по умолчанию будет проверка всеми разумными средствами, и лишь в каких-то редких случаях нужно делать исключения. А не наоборот. Как у безопасников: вайт-листы (запрещать всем, кроме некоторых допущенных) предпочтительнее блэк-листов (разрешать всем, кроме некоторых забаненных).
G>Не надо все делить на "черное" и "белое".
Речь не идёт о «чёрном» или «белом». Речь идёт о «чёрном с проблесками белого» и «о белом с пятнышками чёрного».
G>В некоторых случаях непрохождение некоторых проверок не является критичным (например надо релизнуть в срок). Тем не менее надо постоянно стремиться чтобы все проверки проходились.
Q>Так ведь если задача занимает 8 часов, я обязательно захочу закоммитить промежуточные результаты раз пять, пока её сделаю. Создать точки отката перед рисковыми рефакторингами, etc.
Вопрос конечно интересный. С одной стороны, ваша правда — версионность именно для этого и нужна, а сдругой — создавать ветку каждый день — это как-то странно. А реже — хуже в плане слияния. Ветка разработки чисто психологически хочет жить дольше, хотя должна именно как можно короче.
В общем я привык использовать SVN без философии: нужна ветка — делаем, пока не нужна — коммит напрямую в транк.
Здравствуйте, VGn, Вы писали:
VGn>Вопрос конечно интересный. С одной стороны, ваша правда — версионность именно для этого и нужна, а сдругой — создавать ветку каждый день — это как-то странно. VGn>В общем я привык использовать SVN без философии: нужна ветка — делаем, пока не нужна — коммит напрямую в транк.
Да нет, у нас тоже нет безусловного правила создания ветвей на каждый чих. Как раз CI-сервер амортизирует риски прямых коммитов в транк. Если я вижу последовательность шагов выполнения задачи такую, что позволит часто коммититься, не ломая транк, то я предпочту не плодить сущностей сверх необходимости. Но не всегда такую последовательность можно спрогнозировать, более надёжный способ всё-таки бранч.
VGn>Ветка разработки чисто психологически хочет жить дольше, хотя должна именно как можно короче.
Здравствуйте, avpavlov, Вы писали:
B>>* главная ветка B>>** ветка проекта
A>Не пойму, что такое "ветка проекта"? В чём отличие от главной? Главная — это транк? А ветка проекта — это новая версия?
Типа этого, т.е. главная ветка — это транк.
Когда начинается новый проект, отращивается новая ветка и все делается только там.
