Podlodka Android Crew #12. День 3
Долгий долгий четвёртый день закончился, но мы с вами не торопимся, поэтому обсудим третий.
Первый доклад дня про релизные поезда от Я.Диска. Убедился что наш додошный вариант вполне эффективен, мы не сильно жалуемся. Автоматизацию публикации в сторы мне пока так и не продали. Хотя если публиковать 6 разных сборок по разным магазинам раз в неделю, то я бы тоже призадумался. Когда релиз раз в 3 недели в полтора стора, то как будто и не стоит того.
Интересно было обсудить подход к наполнению Release Notes в этих релизных поездах. Предлагается автоматическое заведение тасков на продактов и, соответственно, на маркетинг, без которых поезд не уедет. Думаю по такому пути и пойдём, а то наши пользователи явно устали от "новых тарифов" больше полугода в каждом релизе. А по хорошему релиз ноуты писать никто не хочет 🙁
На этом фоне ещё порассуждали про упомянутый trunk based подход к гиту. Но я для себя пока так и не определил грань покрытия тестами, начиная с которой не страшно лить всё подряд без тестирования в общую ветку (реквестирую ваш любимый материал на эту тему, хочу вкатиться). Наш а-ля git flow подход явно со страшными оверхедами в области CI пайплайнов и тестирования на мёрж реквестах, но нам он пока даёт такие гарантии, с которыми QA на регрессах не приходится перепроверять все последние изменения. Там где trunk based, там и фичатогглы, поэтому унёс из чатов к себе на размышление то, как бы такую политику сформулировать, чтобы их число не разрасталось настолько неконтролируемо, как это происходит по умолчанию. ✏️
Вторая сессия была круглым столом, где обсуждалось как CI/CD процесс выглядит в маленьких, средних и больших компаниях. И естественно всё скатилось в обсуждение какой-то дичи большой компании, потому что всем интересно. С точки зрения развития кругозора и для того чтобы какой-то офигевший масштаб осознать это наверняка полезно, но на практике не очень. Даже "средний" описанный проект, с моей точки зрения, выглядит уже как суперпродвинутый, это не очень понравилось. По крупицам удалось насобирать идей с чем поиграться. Захотелось затащить к себе dependency-guard, поиграться с dependecy-analysis и talaiot, а до кучи ещё в какой-нибудь импакт анализ занырнуть. Не то чтобы это нам какие-то сумасшедшие профиты принесёт в краткосроке, но с целью собственного развития почему бы и нет.
Ещё одна прозвучавшая за круглым столом мысль, которая пока мне покоя не даёт: зелёный девелоп гарантируется только очередями из мёржреквестов на мёрж при условии того, что на них ещё и все проверки запускаются. А если тебе хочется чтобы мры ещё и быстро от пуша до мёржа продвигались, то это вообще утопия скорее. Отсюда сделал вывод, что процессы выхода из нехороших ситуаций наверно в большинстве кейсов даже важнее, чем защита от попадения в эти нехорошие ситуации. Что впрочем не новость, но именно в смысле работы с гитом и тикетами я об этом видимо ещё не задумывался. Поэтому лучше раз в несколько месяцев сломать общую ветку или пустить проблему в релиз, но иметь процесс это быстро поправить и при этом всегда стабильно быстро работать, без фанатизма в надёжности.
Долгий долгий четвёртый день закончился, но мы с вами не торопимся, поэтому обсудим третий.
Первый доклад дня про релизные поезда от Я.Диска. Убедился что наш додошный вариант вполне эффективен, мы не сильно жалуемся. Автоматизацию публикации в сторы мне пока так и не продали. Хотя если публиковать 6 разных сборок по разным магазинам раз в неделю, то я бы тоже призадумался. Когда релиз раз в 3 недели в полтора стора, то как будто и не стоит того.
Интересно было обсудить подход к наполнению Release Notes в этих релизных поездах. Предлагается автоматическое заведение тасков на продактов и, соответственно, на маркетинг, без которых поезд не уедет. Думаю по такому пути и пойдём, а то наши пользователи явно устали от "новых тарифов" больше полугода в каждом релизе. А по хорошему релиз ноуты писать никто не хочет 🙁
На этом фоне ещё порассуждали про упомянутый trunk based подход к гиту. Но я для себя пока так и не определил грань покрытия тестами, начиная с которой не страшно лить всё подряд без тестирования в общую ветку (реквестирую ваш любимый материал на эту тему, хочу вкатиться). Наш а-ля git flow подход явно со страшными оверхедами в области CI пайплайнов и тестирования на мёрж реквестах, но нам он пока даёт такие гарантии, с которыми QA на регрессах не приходится перепроверять все последние изменения. Там где trunk based, там и фичатогглы, поэтому унёс из чатов к себе на размышление то, как бы такую политику сформулировать, чтобы их число не разрасталось настолько неконтролируемо, как это происходит по умолчанию. ✏️
Вторая сессия была круглым столом, где обсуждалось как CI/CD процесс выглядит в маленьких, средних и больших компаниях. И естественно всё скатилось в обсуждение какой-то дичи большой компании, потому что всем интересно. С точки зрения развития кругозора и для того чтобы какой-то офигевший масштаб осознать это наверняка полезно, но на практике не очень. Даже "средний" описанный проект, с моей точки зрения, выглядит уже как суперпродвинутый, это не очень понравилось. По крупицам удалось насобирать идей с чем поиграться. Захотелось затащить к себе dependency-guard, поиграться с dependecy-analysis и talaiot, а до кучи ещё в какой-нибудь импакт анализ занырнуть. Не то чтобы это нам какие-то сумасшедшие профиты принесёт в краткосроке, но с целью собственного развития почему бы и нет.
Ещё одна прозвучавшая за круглым столом мысль, которая пока мне покоя не даёт: зелёный девелоп гарантируется только очередями из мёржреквестов на мёрж при условии того, что на них ещё и все проверки запускаются. А если тебе хочется чтобы мры ещё и быстро от пуша до мёржа продвигались, то это вообще утопия скорее. Отсюда сделал вывод, что процессы выхода из нехороших ситуаций наверно в большинстве кейсов даже важнее, чем защита от попадения в эти нехорошие ситуации. Что впрочем не новость, но именно в смысле работы с гитом и тикетами я об этом видимо ещё не задумывался. Поэтому лучше раз в несколько месяцев сломать общую ветку или пустить проблему в релиз, но иметь процесс это быстро поправить и при этом всегда стабильно быстро работать, без фанатизма в надёжности.