AR
GitLab же не умеет iOS собирать к примеру у себя, если я правильно помню.
Size: a a a
2019 July 03
EE
GitLab же не умеет iOS собирать к примеру у себя, если я правильно помню.
А разве гитлаб у себя хоть что то умеет собирать? Я не в курсе) там же воркеры ставятся на сервер. Гитлаб дергает воркер, он уже выполняет работу там где стоит
AR
https://about.gitlab.com/product/continuous-integration/
> Continuous Integration is built-in to GitLab
Я так понимаю iOS со своими workers там скорее особняком.
> Continuous Integration is built-in to GitLab
Я так понимаю iOS со своими workers там скорее особняком.
AR
Ну вот для iOS worker как раз на свой "локальный" миник собирался ставить.
EE
Ну вот для iOS worker как раз на свой "локальный" миник собирался ставить.
Можно на общий миник ставить
AR
Ну я имею ввиду на standalone миник, да. Не на тот комп, на котором работаю.
EE
Ну я имею ввиду на standalone миник, да. Не на тот комп, на котором работаю.
А, ок)
AR
А мб кто работает в аутсорс конторах в которых бывают ситуации с 1 человек на прект. Там тоже код ревью делается коллегами с других проектов?
KT
А мб кто работает в аутсорс конторах в которых бывают ситуации с 1 человек на прект. Там тоже код ревью делается коллегами с других проектов?
да
SS
такая же примерно практика была: Юнит тесты на merge реквест в гитлаб, (можно отдельно интеграционные обособить) потом ревью кода, если все ок то ребейз и слив в develop (обычно это master называется)
GitFlow наверное лишний для небольших команд (предположение). Вот это вот мердж фиксов в две ветки...
GitFlow наверное лишний для небольших команд (предположение). Вот это вот мердж фиксов в две ветки...
SS
А мб кто работает в аутсорс конторах в которых бывают ситуации с 1 человек на прект. Там тоже код ревью делается коллегами с других проектов?
Да, нужно максимально стремится к ревью я считаю....хотя когда то это практика была для меня нова и психика во мне сопротивлялась, но быстро принял плюсы....да и сейчас это де-факто в индустрии....хотя вот как фрилансерам хз
SS
А вот такой момент интересен у кого как: ревью делается по коммитам или итогового мерджа?
AR
такая же примерно практика была: Юнит тесты на merge реквест в гитлаб, (можно отдельно интеграционные обособить) потом ревью кода, если все ок то ребейз и слив в develop (обычно это master называется)
GitFlow наверное лишний для небольших команд (предположение). Вот это вот мердж фиксов в две ветки...
GitFlow наверное лишний для небольших команд (предположение). Вот это вот мердж фиксов в две ветки...
Спасибо, а QA билд с мастера делается?
EE
Спасибо, а QA билд с мастера делается?
Разные виды тестовых билдов. Делаются с разных веток
AR
И я правильно понимаю, что фичер-флаги - это больше про крупные продуктвые проекты с регулярным релизным циклом?
SS
1 вариант - комиты аккуратные но могут не собраться, зато проверять проще
2 вариант - комиты сами себя переделывают и тд, любой собирается, но ревью имеет смысл только всё в целом (а это может быть очень много и комит месседжи как то растеряются)
2 вариант - комиты сами себя переделывают и тд, любой собирается, но ревью имеет смысл только всё в целом (а это может быть очень много и комит месседжи как то растеряются)
SS
Спасибо, а QA билд с мастера делается?
Да....были попытки с фичи, но, с одной стороны это зависит от количества тестеров (нагрузки получается через чур если один), с другой за qa-переделками и ревью-переделками есть риск затягивания фичи
Думаю зависит от важности фичи и размера продукта
Думаю зависит от важности фичи и размера продукта
SS
И я правильно понимаю, что фичер-флаги - это больше про крупные продуктвые проекты с регулярным релизным циклом?
Про них не знаю (
OS
И я правильно понимаю, что фичер-флаги - это больше про крупные продуктвые проекты с регулярным релизным циклом?
Нет, от размера не зависит. Зависит от политики (не)бранчевания, наличия CI и умения пилить задачи.
A
Спасибо за ссылку, клёвый доклад.