Что-то основанное на заведомо необходимых черрипиках выглядит плохо.
У каждого инструмента есть свои границы применимости и случаи применения. В случае с TBD cherry-pick применяется только в одной ситуации, причину я также расписал. Если вы делаете по-другому - без проблем, это ваше право.
В мобайле с малыми командами, долгим тестированием и согласованием состава релиза лучше потом много мержить чем постоянно черрипикать
Речь не идет про постоянные черрипики, там всего одна ситуация при релизе, в разработке черрипики вообще не применяются.
Моя статья, скорее, написана для тех, кто уже изучил TBD и хочет попробовать, но столкнулся с какими-то трудностями. Если вас устраивает ваш рабочий процесс и вы не видите причин его менять - не меняйте, оставайтесь на нем.
Видимо конфликты разрешили неправильно. Но это могло случиться и с TBD.
В TBD очень частая синхронизация и атомарные изменения в коде, поэтому чтобы такая ситуация произошла в TBD надо очень постараться. В системах ветвления, которая основана на долгоживущих feature ветках, я такие ситуации вижу регулярно, особенно в активной продуктовой разработке.
Да, так тоже можно. Но на практике, когда мы работали по git flow, я столкнулся со следующей ситуацией. У нас был модуль комментариев, мы отвели ветку и начали делать там новые фичи и доработки. В это время на продакшене находят баг в комментариях, продакт приходит к разработчику, который не работает над комментариями, тот быстро исправляет это в hotfix ветке, выкатывает релиз, hotfix вливает в master. Затем master был влит в ветку комментариев и исправление бага затерлось. Поэтому в следующем релизе на продакшене оказался тот же самый баг.
Проблему, которую я описал, можно исправить несколькими способами. В TBD это исправляется частым вливанием кода в общую ветку разработки. В вашем случае это либо жесткий контроль со стороны тимлида за входящими задачами, либо прокачкой коммуникации внутри команды, наверняка есть еще способы.
Моя статья, скорее, написана для тех, кто уже изучил TBD и хочет попробовать, но столкнулся с какими-то трудностями. Если вас устраивает ваш GitLab Flow и вы не видите причин его менять - не меняйте, оставайтесь на нем.
Сразу хотел бы обозначить, что это не мой подход, он был придуман Paul Hammant в 2017 году. Точнее, он собрал ряд хороших практик в разработке ПО и запаковал их в коробку, которую назвал TBD.
Если кратко, то GitFlow/Gitlab Flow/Github Flow это системы ветвления, а TBD это больше про культуру работы, система ветвления это только часть TBD.
Если подробно, то вот отличия:
В GitLab Flow нет техники branch by abstraction.
В GitLab Flow могут быть feature ветки с долгим временем жизни, в TBD такое не поощряется - feature веток в классическом понимании там нет, работаем как можно более атомарно, хорошим тоном считается вливание своего кода в общую ветку разработки 1 раз в рабочий день.
В GitLab Flow есть pre-production и production ветки. В TBD функцию pre-production веток выполняют release ветки, но они опциональны, в ряде случаев вы можете собирать релиз прямо из trunk. Тут я вижу отличие больше в названии веток. Production веток в GitLab Flow нет.
CI/CD входит в TBD, а вот в GitLab Flow напрямую этого нет. Скорее, в работе вы делаете связку GitLab Flow + CI/CD.
Написание тестов это часть TBD, без них тяжело поддерживать trunk в рабочем состоянии. В GitLab Flow напрямую этого нет.
Сразу оговорюсь, что я не работал с GitLab Flow/Github Flow, поэтому допускаю что мой ответ может быть некорректен в некоторых местах. Информацию для ответа я взял из этой статьи - там же приведено сравнение всех систем ветвления.
В итоге просто число человек в команде без других показателей вообще не говорит ни о чем.
Возможно, я не совсем корректно указал в статье, что на выбор TBD влияет не только отдельные параметры, но и параметры в совокупности. Судя по вашему комментарию, для вас это важно. Спасибо за вашу внимательность, вы помогли мне сделать статью лучше, я оставлю update в статье.
Ну и потом - если у вас большое число конфликтов у двух людей, значит они почему-то правят одни и те же куски кода? Это наводит на мысли, что на самом деле этот код просто обладает излишней связностью, и его бы надо порефакторить, разбив на более независимые куски.
Ситуация про связность кода, которую вы описали, определенно имеет место быть, но она не единственная. В моей практике не раз был случай, когда для бизнеса было важно сделать несколько фич в одном модуле за короткий срок. В таком случае, ваша команда либо часто синхронизируется, как предлагает TBD, либо получаете много merge конфликтов при слиянии нескольких веток, в каждой из которых по несколько дней работы разработчика.
Т.е. качество кода, что бы мы под этим не понимали, чуть ли не более важно при выборе методов работы с ветками в репозитории.
Я с вами согласен, и хотел бы заметить, что в своей статье я как раз упоминаю атомарные коммиты, линтеры, статические анализаторы кода, написание тестов, и другие best practices для разработки качественного кода. TBD, скорее, является набором практик по написанию и доставке качественного кода - интересным и удобным, но, безусловно, не единственным.
При правильно приготовленном TBD такого быть не должно. Возможно, вы не покрываете код тестами, или не соблюдаете атомарность в написании кода, или не делаете должным образом code review, или сразу не исправляете сломанный trunk - причин может быть множество. Будет здорово если вы побольше расскажете про контекст.
Гораздо удобнее сделать полную фичу в долгой или очень долгой ветке
А есть ли у вас конфликты при слиянии кода, которые требуют много времени на исправление? Есть ли случаи, когда разработчики дублируют свою работу по исправлению багов, потому что каждый работает в своей ветке по нескольку дней?
Посыл моей статьи в том, что сначала нужно проанализировать нужен ли вам TBD в принципе. Если вы решили что нужен, а потом попробовали и поняли что не нужен или неудобен - отказаться от него это тоже хорошее решение.
Размер команды это не единственный параметр для выбора в пользу TBD. У меня в одной из команд было 2 человека, но там была очень активная разработка с большим числом merge conflicts и потребностью в постоянной синхронизации кода между разработчиками. TBD решил эту проблему.
В другой команде было 3 человека, но там все итак хорошо работало, поэтому смысла завозить TBD не было.
Поэтому важно смотреть не только на какой-то один параметр, но и на все параметры в совокупности.
Rx уже стал стандартом де-факто в разработке — сложно найти проекты, которые его не используют, поэтому он имеет огромное комьюнити, которое его поддерживает в актуальном состоянии. Я к тому, что хоть это действительно сторонний фреммворк, он имеет огромный вес на рынке и его понимание прямо сейчас является необходимостью в большинстве вакансий.
А зачем такое жесткое разделение на реактивные и нереактивные тесты? Понятно что реактивная и нереактивная логика всегда будут рядом, т.к. обмазываться Rx'ом по всему проекту практика достаточно странная. Что вам мешает это смешивать?
Нвпример, у нас в команде используется RxTest, RxBlocking, SwiftyMocky для генерации моков и тестирования вызовов функций в моках, iOSSnapshotTestCase тесты от убера, ну и родные UI тесты и XCTest. Итого 6 тестов различных видов, которые очень сильно автоматизируют нашу работу по созданию моков и работу QA при регрессе/смоках приложений. Все эти тесты вполне себе хорошо живут рядом и не мешают друг другу
По поводу плохой тестируемости реактивного кода не соглашусь. На RayWenderlich есть классная статья, а также недавно подъехал перевод этой статьи на хабре.
Реактивный код вполне себе хорошо и удобно тестируется. Возможно, не так удобно как слои в VIPER, но в 2016 году, когда я писал вот эту статью, было гораздо неудобней.
Ну тут где как. У нас на каждый день недели есть ответственный за ревью + кто-то из старших программистов обычно старается смотреть. Как правило, 2 одобрения минимум MR собирает. Если какой-то критический MR, который вносит изменение в работу других членов команды, то его должны просмотреть и одобрить все члены команды, чтобы потом не было вопросов.
Мой коллега kurenkoff немного ошибся. Мы действительно на клиенте можем получить identityToken. Решили использовать вместо него authorizationCode по соображениям безопасности, т.к. он имеет короткое время жизни.
При желании, можно делать как вы говорите — получать identityToken на клиенте и кидать его на сервер. Это вопрос конкретной реализации.
Так RIB это как раз нативный подход, приложения пишутся на родных для платформ языках. У Uber в репозитории это Swift и Java. Просто Uber постарались разработать архитектуру так, чтобы она была максимально похожа на обеих платформах. Возможно, слово «кроссплатформенность» в заголовке ввело вас в заблуждение, но в оригинальной статье написано именно оно.
Монстр совсем не новый, ему уже года 2, если не больше :-)
В целом, у каждого программиста был неудачный опыт с какой-нибудь архитектурой. И у меня он тоже был, я прекрасно понимаю ваше легкое негодование по поводу очередной архитектуры. Если бы архитектура была не очень продуманной, то я бы не стал тратить время на перевод этой статьи. Часть работы программиста это изучать новые подходы для того, чтобы писать более расширяемую архитектуру и безопасный код.
Так что я призываю вас к конструктиву — ознакомиться с инструментом получше, составить его плюсы и минусы для себя, ну и далее я с удовольствием пообщаюсь с вами на эту тему. Также было бы здорово узнать какой подход в разработке применяете лично вы, возможно у вас есть какая-то хорошая альтернатива, о которой я не знаю :-)
Моя позиция по этому вопросу следующая:
1. Прежде чем что-то изучать, я смотрю как это работает в проекте, пусть даже тестовом. Это мне помогает понять, стоит ли вообще тратить время на изучение фреймворка/подхода. Не раз натыкался на вещи, которые выглядят интересно, но практическое применение в коде было не очень удачным. К слову, все мои статьи имеют тестовые проекты, в которых сразу можно опробовать подход/технологию.
2. На хабре есть и начинающие программисты, которым зачастую бывает сложно применить фреймворк/подход в коде (как тимлид говорю). Им проще всего скачать проект, посмотреть как там это используется и применить уже у себя.
Ну это так, пожелания. Вы вполне вольны их не учитывать. В любом случае — спасибо за статью!
Здравствуйте! Я — автор статьи про Moya, которую Вы процитировали в самом начале.
Интересный подход, хотелось бы увидеть его в деле в виде какого-нибудь тестового проекта. Разумеется, я и сам могу накатать код, но код автора подхода тоже было бы интересно посмотреть :)
Ровно с этого и началась моя статья. Вот выдержка из второго абзаца статьи:
Я даже сделал отдельный небольшой раздел под названием "Нужен ли вам TBD?".
В любом случае - спасибо за ваше мнение!
Здравствуйте! Благодарю вас за комментарий.
У каждого инструмента есть свои границы применимости и случаи применения. В случае с TBD cherry-pick применяется только в одной ситуации, причину я также расписал. Если вы делаете по-другому - без проблем, это ваше право.
Речь не идет про постоянные черрипики, там всего одна ситуация при релизе, в разработке черрипики вообще не применяются.
Моя статья, скорее, написана для тех, кто уже изучил TBD и хочет попробовать, но столкнулся с какими-то трудностями. Если вас устраивает ваш рабочий процесс и вы не видите причин его менять - не меняйте, оставайтесь на нем.
В TBD очень частая синхронизация и атомарные изменения в коде, поэтому чтобы такая ситуация произошла в TBD надо очень постараться. В системах ветвления, которая основана на долгоживущих feature ветках, я такие ситуации вижу регулярно, особенно в активной продуктовой разработке.
Да, так тоже можно. Но на практике, когда мы работали по git flow, я столкнулся со следующей ситуацией. У нас был модуль комментариев, мы отвели ветку и начали делать там новые фичи и доработки. В это время на продакшене находят баг в комментариях, продакт приходит к разработчику, который не работает над комментариями, тот быстро исправляет это в hotfix ветке, выкатывает релиз, hotfix вливает в master. Затем master был влит в ветку комментариев и исправление бага затерлось. Поэтому в следующем релизе на продакшене оказался тот же самый баг.
Проблему, которую я описал, можно исправить несколькими способами. В TBD это исправляется частым вливанием кода в общую ветку разработки. В вашем случае это либо жесткий контроль со стороны тимлида за входящими задачами, либо прокачкой коммуникации внутри команды, наверняка есть еще способы.
Моя статья, скорее, написана для тех, кто уже изучил TBD и хочет попробовать, но столкнулся с какими-то трудностями. Если вас устраивает ваш GitLab Flow и вы не видите причин его менять - не меняйте, оставайтесь на нем.
Здравствуйте! Благодарю вас за комментарий.
Сразу хотел бы обозначить, что это не мой подход, он был придуман Paul Hammant в 2017 году. Точнее, он собрал ряд хороших практик в разработке ПО и запаковал их в коробку, которую назвал TBD.
Если кратко, то GitFlow/Gitlab Flow/Github Flow это системы ветвления, а TBD это больше про культуру работы, система ветвления это только часть TBD.
Если подробно, то вот отличия:
В GitLab Flow нет техники branch by abstraction.
В GitLab Flow могут быть feature ветки с долгим временем жизни, в TBD такое не поощряется - feature веток в классическом понимании там нет, работаем как можно более атомарно, хорошим тоном считается вливание своего кода в общую ветку разработки 1 раз в рабочий день.
В GitLab Flow есть pre-production и production ветки. В TBD функцию pre-production веток выполняют release ветки, но они опциональны, в ряде случаев вы можете собирать релиз прямо из trunk. Тут я вижу отличие больше в названии веток. Production веток в GitLab Flow нет.
CI/CD входит в TBD, а вот в GitLab Flow напрямую этого нет. Скорее, в работе вы делаете связку GitLab Flow + CI/CD.
Написание тестов это часть TBD, без них тяжело поддерживать trunk в рабочем состоянии. В GitLab Flow напрямую этого нет.
Сразу оговорюсь, что я не работал с GitLab Flow/Github Flow, поэтому допускаю что мой ответ может быть некорректен в некоторых местах. Информацию для ответа я взял из этой статьи - там же приведено сравнение всех систем ветвления.
Здравствуйте! Благодарю вас за комментарий.
Если вас в полной мере устраивает git-flow - отлично, используйте его дальше. TBD вам не нужен.
Возможно, я не совсем корректно указал в статье, что на выбор TBD влияет не только отдельные параметры, но и параметры в совокупности. Судя по вашему комментарию, для вас это важно. Спасибо за вашу внимательность, вы помогли мне сделать статью лучше, я оставлю update в статье.
Ситуация про связность кода, которую вы описали, определенно имеет место быть, но она не единственная. В моей практике не раз был случай, когда для бизнеса было важно сделать несколько фич в одном модуле за короткий срок. В таком случае, ваша команда либо часто синхронизируется, как предлагает TBD, либо получаете много merge конфликтов при слиянии нескольких веток, в каждой из которых по несколько дней работы разработчика.
Я с вами согласен, и хотел бы заметить, что в своей статье я как раз упоминаю атомарные коммиты, линтеры, статические анализаторы кода, написание тестов, и другие best practices для разработки качественного кода. TBD, скорее, является набором практик по написанию и доставке качественного кода - интересным и удобным, но, безусловно, не единственным.
Здравствуйте! Благодарю вас за комментарий.
При правильно приготовленном TBD такого быть не должно. Возможно, вы не покрываете код тестами, или не соблюдаете атомарность в написании кода, или не делаете должным образом code review, или сразу не исправляете сломанный trunk - причин может быть множество. Будет здорово если вы побольше расскажете про контекст.
А есть ли у вас конфликты при слиянии кода, которые требуют много времени на исправление? Есть ли случаи, когда разработчики дублируют свою работу по исправлению багов, потому что каждый работает в своей ветке по нескольку дней?
Посыл моей статьи в том, что сначала нужно проанализировать нужен ли вам TBD в принципе. Если вы решили что нужен, а потом попробовали и поняли что не нужен или неудобен - отказаться от него это тоже хорошее решение.
Здравствуйте! Благодарю вас за комментарий.
Размер команды это не единственный параметр для выбора в пользу TBD. У меня в одной из команд было 2 человека, но там была очень активная разработка с большим числом merge conflicts и потребностью в постоянной синхронизации кода между разработчиками. TBD решил эту проблему.
В другой команде было 3 человека, но там все итак хорошо работало, поэтому смысла завозить TBD не было.
Поэтому важно смотреть не только на какой-то один параметр, но и на все параметры в совокупности.
Rx уже стал стандартом де-факто в разработке — сложно найти проекты, которые его не используют, поэтому он имеет огромное комьюнити, которое его поддерживает в актуальном состоянии. Я к тому, что хоть это действительно сторонний фреммворк, он имеет огромный вес на рынке и его понимание прямо сейчас является необходимостью в большинстве вакансий.
А зачем такое жесткое разделение на реактивные и нереактивные тесты? Понятно что реактивная и нереактивная логика всегда будут рядом, т.к. обмазываться Rx'ом по всему проекту практика достаточно странная. Что вам мешает это смешивать?
Нвпример, у нас в команде используется RxTest, RxBlocking, SwiftyMocky для генерации моков и тестирования вызовов функций в моках, iOSSnapshotTestCase тесты от убера, ну и родные UI тесты и XCTest. Итого 6 тестов различных видов, которые очень сильно автоматизируют нашу работу по созданию моков и работу QA при регрессе/смоках приложений. Все эти тесты вполне себе хорошо живут рядом и не мешают друг другу
Реактивный код вполне себе хорошо и удобно тестируется. Возможно, не так удобно как слои в VIPER, но в 2016 году, когда я писал вот эту статью, было гораздо неудобней.
При желании, можно делать как вы говорите — получать identityToken на клиенте и кидать его на сервер. Это вопрос конкретной реализации.
В плане натива я с вами полностью согласен.
В целом, у каждого программиста был неудачный опыт с какой-нибудь архитектурой. И у меня он тоже был, я прекрасно понимаю ваше легкое негодование по поводу очередной архитектуры. Если бы архитектура была не очень продуманной, то я бы не стал тратить время на перевод этой статьи. Часть работы программиста это изучать новые подходы для того, чтобы писать более расширяемую архитектуру и безопасный код.
Так что я призываю вас к конструктиву — ознакомиться с инструментом получше, составить его плюсы и минусы для себя, ну и далее я с удовольствием пообщаюсь с вами на эту тему. Также было бы здорово узнать какой подход в разработке применяете лично вы, возможно у вас есть какая-то хорошая альтернатива, о которой я не знаю :-)
1. Прежде чем что-то изучать, я смотрю как это работает в проекте, пусть даже тестовом. Это мне помогает понять, стоит ли вообще тратить время на изучение фреймворка/подхода. Не раз натыкался на вещи, которые выглядят интересно, но практическое применение в коде было не очень удачным. К слову, все мои статьи имеют тестовые проекты, в которых сразу можно опробовать подход/технологию.
2. На хабре есть и начинающие программисты, которым зачастую бывает сложно применить фреймворк/подход в коде (как тимлид говорю). Им проще всего скачать проект, посмотреть как там это используется и применить уже у себя.
Ну это так, пожелания. Вы вполне вольны их не учитывать. В любом случае — спасибо за статью!
Интересный подход, хотелось бы увидеть его в деле в виде какого-нибудь тестового проекта. Разумеется, я и сам могу накатать код, но код автора подхода тоже было бы интересно посмотреть :)