У меня клон основного рабочего репозитория занимает порядка пяти гигабайт, с чекаутом получается в районе десяти (не говоря уже, что со всеми артефактами сборки около 70) И там тормоза уже сильно заметны. Если интересно, могу рассказать подробнее про медленные/быстрые команды git, но это скорее всего тянет на отдельный пост.
Книжку рекомендую прочитать полностью. Наступает просветление, понимание того, как гит устроен, что в нем можно сделать, а что нельзя. Еще приходит осознание, какие операции быстрые, а какие тормозные (многим это не актуально, но если работать с гигантскими репозиториями, это очень полезные знания).
Ну не скажите… Я запускал большие прожорливые java приложения от jetbrains & atlassian, там не мудрено упираться в память. А модные хипстерские фреймворки на память еще прожорливее.
Печально, только, что увеличив количество ядер вчетверо и максимальную тактовую частоту почти вдвое, оставили те же 2GB оперативки. Они на CB3 то жали иногда, а тут...
И нигде не упомянули цену, это чудо продают по $99 за штуку.
Кучу всякой ненужной гуйни перечислили, а iterm и homebrew забыли.
И еще в копилку: скрипты ios-deploy и ios-sim из phonegap весьма полезны, с ними можно писать код в нормальном текстовом редакторе (а не в убогом xcode), собирать проект с помощью xcodebuild и потом деплоить на устройство/в симулятор, не открывая xcode.
Открыл в сафари 9 на OS X 10.11. Забавно, на глаз я вижу, что до разделителя есть переход между двумя разными, но очень похожими цветами. Но pixie (graphics tools for xcode 7), говорит, что это один цвет srgb(0.0, 0.5, 0.0).
Ревью кода производится до мерджа. Только когда все owner-ы кода отписали LGTM, без этого не пройдет pre_commit сборка. После этого можно нажать кнопку commit, пр попадет в commit-queue и для него соберутся сборки. Если сборки зеленые, то код коммитится в мастер. Вот пример ревью, в котором были и притензии к коду и падающие сборки и четыре owner-а измененного кода: codereview.chromium.org/673623002
Робот отписывает в задачу, в какие ветки попал связный патч. Робот же не дает влить патч в ветку, если в задаче не проставлена нужная версия.
Задача закрывается когда патчи для нее попали во все требуемые ветки (это контролирует разработчик).
Тесты прогоняются перед вливанием патча. Патч не вливается, если они не проходят.
Ветка живет шесть недель, этого достаточно чтобы провести несколько этапов тестирования и починить все обнаруженные баги.
На нашей инфраструктуре по сути не имеет смысла трекать историю черри-пика, все равно всегда можно найти соответствующие пулл-реквест и задачу. А подобные баги мы ловим тысячами тестов и тестированием силами команды qa. Да и черни-пики сами по себе, как правило это баг-фиксы, фичи, которые не попали в мастер до отвода релизной ветки в эту ветку не попадают.
Это автоматизированное действие. Уже почти два года практически никогда никто не делает черрипики вручную. В момент создания пулл-реквеста в мастер указывается, в каких ветках нужен этот код и пулл-реквесты с черри-пиками в них будут созданы автоматически. Разве что иногда появляются конфликты и робот просит сделать черепки руками и запушить его в ветку, из которой он сделает пулл-реквест. Это был чуть ли не самый ожидаемый плагин к стешу от группы инфраструктуры (после автомерджа, конечно).
А зачем хранить на сервере исходный код и среду сборки? Да для разработки это удобно, но в продакшне ни то, ни другое не нужно. Там даже шелл не стоит хранить, если он не нужен самому приложению.
К сожалению нет. Небольшая часть этого есть в pro git. Оставшаяся же часть осваивается посредством долгого и вдумчивого ковыряния в git на практике.
Действительно, ожидал увидеть мясо про rev-parse, for-each-ref, cat-file, rebase --onto, fetch +, update-ref, show-ref… А тут просто пачка алиасов.
У меня клон основного рабочего репозитория занимает порядка пяти гигабайт, с чекаутом получается в районе десяти (не говоря уже, что со всеми артефактами сборки около 70) И там тормоза уже сильно заметны. Если интересно, могу рассказать подробнее про медленные/быстрые команды git, но это скорее всего тянет на отдельный пост.
Книжку рекомендую прочитать полностью. Наступает просветление, понимание того, как гит устроен, что в нем можно сделать, а что нельзя. Еще приходит осознание, какие операции быстрые, а какие тормозные (многим это не актуально, но если работать с гигантскими репозиториями, это очень полезные знания).
Имхо, не лучшее описание темы. В pro git написано сильно понятнее и целостнее. Вся десятая глава про это: https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain
Ну не скажите… Я запускал большие прожорливые java приложения от jetbrains & atlassian, там не мудрено упираться в память. А модные хипстерские фреймворки на память еще прожорливее.
Я пытался использовать CB3 как маленькие сервера (git/ci/sandbox/testing), и несколько раз упирался именно в память.
Печально, только, что увеличив количество ядер вчетверо и максимальную тактовую частоту почти вдвое, оставили те же 2GB оперативки. Они на CB3 то жали иногда, а тут...
И нигде не упомянули цену, это чудо продают по $99 за штуку.
Спасибо, унес в заметки.
Кучу всякой ненужной гуйни перечислили, а iterm и homebrew забыли.
И еще в копилку: скрипты ios-deploy и ios-sim из phonegap весьма полезны, с ними можно писать код в нормальном текстовом редакторе (а не в убогом xcode), собирать проект с помощью xcodebuild и потом деплоить на устройство/в симулятор, не открывая xcode.
Задача закрывается когда патчи для нее попали во все требуемые ветки (это контролирует разработчик).
Тесты прогоняются перед вливанием патча. Патч не вливается, если они не проходят.
Ветка живет шесть недель, этого достаточно чтобы провести несколько этапов тестирования и починить все обнаруженные баги.