Comments 51
Действительно интересно было почитать, как серьёзные компании делают продукты, находящиеся в центре внимания миллионов людей.
И, как всегда, некоторые вещи удивляют — например, заходя сюда, я ожидал увидеть сложные механизмы CI, а взамен — пара бранчей и вообще всё проще и надёжнее, чем казалось.
И, как всегда, некоторые вещи удивляют — например, заходя сюда, я ожидал увидеть сложные механизмы CI, а взамен — пара бранчей и вообще всё проще и надёжнее, чем казалось.
Если стало интересно, то в продолжение темы есть видео с субтитрами на английском с Google Test Automation Conference 2014.
Да, очень круто. Хотелось бы когда-нибудь в жизни поработать в подобной команде)
Я бы не советовал :) Крупный проект — это всегда отвратительное сочетание колоссальной ответственности и колоссальной же беспомощности.
Другими словами, это одна их тех областей жизни, про которую интереснее читать, чем в ней участвовать.
Я не сказал, что это неинтересно. Я приведу параллель. Работать спасателем в МЧС интересно. Изучать смертельные вирусы интересно. Ловить преступников интересно. Все эти занятия очень интересны — вряд ли кто-то станет отрицать.
Разумеется, это — гротеск. Но смысл, надеюсь, ясен. Проблема не в том, что интересно, а в том, чего это может/будет вам стоить.
Разумеется, это — гротеск. Но смысл, надеюсь, ясен. Проблема не в том, что интересно, а в том, чего это может/будет вам стоить.
Хотел спросить: В Chromium есть какие то бэкдор механизмы или прочие механизмы для отслеживания пользователей? После информации, которую опубликовал Сноуден, как то стремно доверять большим пиндосовским компаниям типа Google.
Так Интернет и прочее — тоже «пиндосовское» изобретение… Как вы в нем сидите то? =)
Изобретение да, пиндосовское. Но интернет не пиндосовский. Все таки есть огромное количество проектов, которые разрабатываются сообществом из всего мира и не находятся под коммерческим управлением.
А сети и каналы связи как? Тоже сообщество поддерживает?)
Сети и каналы связи неважно кто поддерживает. Главное чтобы информация через эти каналы связи проходила в зашифрованном виде.
… пока что каналы связи к сожалению поддерживаются коммерческими предприятиями. Но я считаю что будущее интернета именно за так называемыми Mesh-сетями (https://en.wikipedia.org/wiki/Mesh_networking)
Chromium это OpenSource проект, наличие закладок в нём маловероятно. А вот в основанном на нём Chrome да, их наличие гарантировано.
Доверять никому нельзя. Даже себе.
Мюллер
UFO just landed and posted this here
С Chrome этот подход не сработает, поскольку мы релизимся каждый день. Мы не можем допустить внезапного появления в нашем trunk больших кусков нового кода, поскольку в таком случае велика вероятность, что каналы обновления canary или dev надолго уйдут в отказ. Кроме того, trunk в Chrome движется вперед с такой скоростью, что для разработчиков непрактично оставаться изолированными на своей ветке на слишком долгий промежуток времени. К тому времени, когда они смержат свою ветку, trunk будет выглядеть настолько по-другому, что интеграция будет трудоемкой и легко подвержена ошибкам.Так и запишем — разработку в ветках не осилили. Детский сад какой-то.
действительно детский сад:
— работа в ветках предполагает как минимум ежедневный мерж транка в свою ветку или чаще в зависимости от объема, в результате потом финальный мерж в транк проходит беспроблемно, ничего не изолированно и не уйдет в отказ если руки прямые.
Кроме того, trunk в Chrome движется вперед с такой скоростью, что для разработчиков непрактично оставаться изолированными на своей ветке на слишком долгий промежуток времени.
— работа в ветках предполагает как минимум ежедневный мерж транка в свою ветку или чаще в зависимости от объема, в результате потом финальный мерж в транк проходит беспроблемно, ничего не изолированно и не уйдет в отказ если руки прямые.
rebase
Терять историю изменений — это очень «разумно». Вообще работа с ветками в гите — так себе. В меркуриале гораздо лучше.
WAT? Когда это rebase убивал историю?
Всегда. Это его основная функция. Или по вашему история — это только содержимое изменений без информации о том, в каком контексте они сделаны?
Знаете, насчет меркуриала — когда я узнал, что там, в отличие от git, сохраняется пометка о ветке в каждом коммите, тоже сперва восхитился. А потом понял, что расхождение тут — идеологическое. И понял, что идеология git-а разумнее. И состоит она, как мне кажется, в следующем:
1. Все разработчики коммитят проект последовательно. Для того, чтобы исключить «технические мержи», существует rebase. (У нас в команде уже полгода десять человек успешно живут втодной ветке и радуются жизни).
2. А для чего ветки? Для того, чтобы поддерживать несколько разных версий продукта одновременно. То есть, понимаете ли, если вы заранее знаете, что завтра вы изменения смержите в master, то делать для них отдельную ветку — не комильфо. Вообще, мержи — это фу-фу-фу. Они нужны только в самом экстренном случае. А если вы хотите накатить изменение на 5 веток сразу, то тут есть cherry-pick.
3. (Самый главный аргумент в пользу логики гита) Если вы-таки уже смержили одну ветку в другую, то не все ли равно, в какой из них были выполненные ранее изменения? Вы теперь эту ветку вообще можете удалить — разницы в итоге не будет. Нет ее больше. Всё. Если вы теперь в нее коммитите, то по сути вы ее заново отращиваете.
При таком подходе «дерево коммитов» действительно будет деревом, а не паутиной.
1. Все разработчики коммитят проект последовательно. Для того, чтобы исключить «технические мержи», существует rebase. (У нас в команде уже полгода десять человек успешно живут втодной ветке и радуются жизни).
2. А для чего ветки? Для того, чтобы поддерживать несколько разных версий продукта одновременно. То есть, понимаете ли, если вы заранее знаете, что завтра вы изменения смержите в master, то делать для них отдельную ветку — не комильфо. Вообще, мержи — это фу-фу-фу. Они нужны только в самом экстренном случае. А если вы хотите накатить изменение на 5 веток сразу, то тут есть cherry-pick.
3. (Самый главный аргумент в пользу логики гита) Если вы-таки уже смержили одну ветку в другую, то не все ли равно, в какой из них были выполненные ранее изменения? Вы теперь эту ветку вообще можете удалить — разницы в итоге не будет. Нет ее больше. Всё. Если вы теперь в нее коммитите, то по сути вы ее заново отращиваете.
При таком подходе «дерево коммитов» действительно будет деревом, а не паутиной.
1. А что плохого в технических мержах? Они чётко дают понять, что вот тут фичеветка А была влита в мастер, а вот тут для неё были сделаны дополнительные фиксы, которые потом тоже попали в мастер. А с ребейсом у вас для дофикса нужно заводить отдельную ветку. А потом вам нужно вашу фичу отправить в релиз без остальных и начинается полуручной перенос кода черипиками.
2. Я не знаю, когда я смержу в мастер. Может тестировщики найдут критикал баг и конктрено мою фичу придётся отложить.
3. Не всё равно. История необходима, чтобы понять где и почему была допущена та или иная ошибка. Банально после rebase у вас может отвалиться bisect, так как вы банально не сможете сбилдить промежуточные коммиты. Подробности: http://habrahabr.ru/post/179673/
2. Я не знаю, когда я смержу в мастер. Может тестировщики найдут критикал баг и конктрено мою фичу придётся отложить.
3. Не всё равно. История необходима, чтобы понять где и почему была допущена та или иная ошибка. Банально после rebase у вас может отвалиться bisect, так как вы банально не сможете сбилдить промежуточные коммиты. Подробности: http://habrahabr.ru/post/179673/
UFO just landed and posted this here
events.yandex.ru/lib/talks/2588 — должно быть вам будет интересно.
Там почти тот же gitflow. Разве что черрипик коммитов между ветками — это жесть.
Это автоматизированное действие. Уже почти два года практически никогда никто не делает черрипики вручную. В момент создания пулл-реквеста в мастер указывается, в каких ветках нужен этот код и пулл-реквесты с черри-пиками в них будут созданы автоматически. Разве что иногда появляются конфликты и робот просит сделать черепки руками и запушить его в ветку, из которой он сделает пулл-реквест. Это был чуть ли не самый ожидаемый плагин к стешу от группы инфраструктуры (после автомерджа, конечно).
Жесть не потому, что вручную, а потому, что перенос патчей не трекается полноценно системой контроля версий со всеми вытекающими (привет, SVN < 1.5). И это не говоря о том, что перенос патчей с пропусками череват появлением багов вида «патч неявно зависит от состояния кода, достигнутого другим патчем, который не был перенесён так как относится к другой фиче».
На нашей инфраструктуре по сути не имеет смысла трекать историю черри-пика, все равно всегда можно найти соответствующие пулл-реквест и задачу. А подобные баги мы ловим тысячами тестов и тестированием силами команды qa. Да и черни-пики сами по себе, как правило это баг-фиксы, фичи, которые не попали в мастер до отвода релизной ветки в эту ветку не попадают.
Как вы узнаёте в какие ветки попал определённый патч?
Как вы узнаёте все ли патчи попали в определённую ветку?
Прогон тысяч тестов — несколько часов до фидбэка
Прогон тестировщиков — несколько дней до фидбека
Как вы узнаёте все ли патчи попали в определённую ветку?
Прогон тысяч тестов — несколько часов до фидбэка
Прогон тестировщиков — несколько дней до фидбека
Робот отписывает в задачу, в какие ветки попал связный патч. Робот же не дает влить патч в ветку, если в задаче не проставлена нужная версия.
Задача закрывается когда патчи для нее попали во все требуемые ветки (это контролирует разработчик).
Тесты прогоняются перед вливанием патча. Патч не вливается, если они не проходят.
Ветка живет шесть недель, этого достаточно чтобы провести несколько этапов тестирования и починить все обнаруженные баги.
Задача закрывается когда патчи для нее попали во все требуемые ветки (это контролирует разработчик).
Тесты прогоняются перед вливанием патча. Патч не вливается, если они не проходят.
Ветка живет шесть недель, этого достаточно чтобы провести несколько этапов тестирования и починить все обнаруженные баги.
А знаете, кто еще «не осилил»? Ребята, которые придумали Continuous integration. Почитайте на досуге. Кто что «осилил» — всегда открытый вопрос.
Данная стратегия означает, что работа над новыми фичами интегрирована в код проекта с самого начала в максимально возможном объеме.
Есть ли какие способы в подходе «одной ветки» гарантирующие, что новая, еще не законченная фича, которая не должна выезжать на пользователей, выедет, и это повлечет результат, сравнимый с недавним факапом Яндекса?
В стандартном подходе «фича — ветка» предполагается, что ветка мерджится в основную только после завершения задачи, и, как следствие, готова к релизу.
Нет тут никаких гарантий и быть не может. Всё держится на условиях времени исполнения. При этом не редки случаи, когда фичи сами по себе работают, а при включении обоих флагов что-нибудь где-нибудь ломается. При этом все n^2 комбинаций флагов разумеется никто не тестирует. То есть надеются на авось и на суровый профессионализм C++ разработчиков, привыкших к undefined bahaviour.
Статья слегка не актуальна. Вчера код blink был вмерджен в основной репозиторий chromium.
Единственное, что не раскрыли — версионирование. С каких пор версии полетели как самолёт по взлётке? Чем 45 так отличается от 44, например, что она не 44.0.1? Я как пользователь вообще разницы не вижу
Просто кажды релиз они прибавляют +1 к версии. А учитывая что релиз каждые 6 недель — в год выходит 8-9 версий. И не важно, насколько крутые изменения были. В этом плане мне нравится больше подход Яндекс.Браузера или Ubuntu, где версия выглядит так: год.месяц — все четко, и понятно, и нет таких гигантских чисел даже при минимальных изменениях функционала.
Ну ведь согласитесь — это тупо. Для проектов в вечном rolling release есть yy.mm.dd, как вы верно заметили, для всего остального — major.minor.patch. Ох уж эта гонка за цифрами!
Согласен. Мне кажется yy.mm.dd можно было бы вообще ко всем проектам применять, для тех которые релизятся раз в год и реже — уу(Visual Studio 2015), которые чаще чем в раз год, но не чаще раза в месяц — уу.mm (Yandex.Browser 15.10), а для тех, которые пару раз в месяц и чаще — либо yy.mm.dd либо yy.mm.nn(где nn — порядковый номер релиза в текущем месяце, примеров известных вспомнить не могу)
Значит ли это, что ревью кода делается когда он уже в стволе? Как быть в таком случае с джуниорами, которые коммитят всякий трэш?
Очевидно, они могу себе позволить нанимать только сеньоров :-)
Ревью кода производится до мерджа. Только когда все owner-ы кода отписали LGTM, без этого не пройдет pre_commit сборка. После этого можно нажать кнопку commit, пр попадет в commit-queue и для него соберутся сборки. Если сборки зеленые, то код коммитится в мастер. Вот пример ревью, в котором были и притензии к коду и падающие сборки и четыре owner-а измененного кода: codereview.chromium.org/673623002
Sign up to leave a comment.
Как работают над Chromium