Миша, не оставляй канал, у тебя один из самых крутых IT каналов в ru youtube. Просто все привыкли к контенту "c++ за час" и тому подобное. Я считаю что твой канал и канал SOER, люди обделяют вниманием потому что процентов 70% зрителя IT каналов это "Вайтишники". Скоро они все отработают по пол годика и научаться отличать полезный контент от сказочного, а пока держись и не сдавайся. С удовольствием смотрю все твои видео, удачи.
@@programisli Было бы интересно послушать про архитектуру. Как писать код чисто, чтобы потом было меньше багов в итоге, либо как избегать таких ситуаций.
Честно говоря, вообще удивлен, что у кого-то есть такое представление о CI ) Видимо, сказывается опыт. Для меня CI - это просто автоматический запуск тестов (и других проверок) в системе контроля версий, чтобы не слить невалидный код в мастер ветку. Иными словами, CI мы используем не вместО, а вместЕ с ветвлением. Да и то, что кто-то, используя гит, не делает фича-веток, тоже звучит как новость из параллельной вселенной, если честно ) Но спасибо за то, что делитесь опытом!
да не ci какая-то пижня. работаю по гитфлоу. иногда функционал нужно перенести в другой релиз и тогда ветка просто ждёт своей очереди на слияние. иногда разработка долгая в несколько сервисах. 3 дня на первый сервис, потом 3 дня на второй и ещё 3 на третий, в таком случае ci будет постоянно ломаться. да и тестировщикам проще когда поведение в ветке ожидаемо, когда он тестирует определенную фичу. если тестеровщик будет тестировать фичу в общей ветке, ему нужно еще как-то узнать о всех фичах доработках в общей ветке иначе будет миллион запросов: а почему это работает так, а почему тут теперь иное поведение и тд
Такое ещущение, что под CI тут имеется в виду trunk-based development (SVN-style), в моем понимании CI и GitFlow все-таки праллельные вещи. В общепринятом смысле CI вполне работает вместе с git flow (и очень хорошо). От trunk-based всегда бегу с ужасом - с ним больше проблем, чем бенефитов, с git flow же все атомарно, нормальная история, тесты гоняются после коммита во всех ветках, пожтому автора изначального посыла считаю не правым и скорее всего, если им плохо живется с ветками - есть какие-то проблемы в архитектуре приложения/бизнесс процессах и т.д
У нас на работе тоже мусорят прямо в мастер, не каждый код ревью способен увидеть баги, поэтому от молодых регулярно проскакивают косяки, ломающие сайт.
Так и не понял, почему нельзя при CI использовать бранчевание и поставку на стэйджинг где уже QA проводят приёмочное тестирование (а если надо, то и демо для кастомера). И всё это с регулярной актуализацией из мастера. И уже когда фича готова - она вмерживается к запланированной поставке в мастер. Более того, например, в вики про непрерывную интеграцию именно так и предлагают: > эта проблема может решаться созданием отдельной «ветки» (англ. branch) проекта для внесения крупных изменений (код, разработка которого до работоспособного варианта займет несколько дней, но желательно более частое сохранение результата в репозиторий). По окончании разработки и индивидуального тестирования такой ветки, она может быть объединена (merge) с основным кодом
Если три программиста пишут в своих ветках и не интегрируют свой код в мастер, то они не видят изменений друг друга, поэтому сторонники постоянной интеграции рекомендуют мерджить в мастер как можно чаще
@@programisli Кто-то закончил фичу, вмержил в мастер, раскатал - остальные забрали из мастера и в этот момент вмержили свой код с итоговым вариантом, не тратя время на стопицот промежуточных решений и их мержи, с мержами, с мержами с предыдущими фичами и мержами мержей. При этом разработчик фичи лучше понимает как правильно свою фичу подмержить в основной код. А вот когда там параллельно копошится много человек (что уже само по себе несколько странно и напряжно), можно сойти с ума пока смержишься и тем более такое нельзя ставить на более-менее адекватном проекте в прод. И так проще разобраться, какая поставка сломала что-то. В общем если более двух разработчиков - однозначно нужно бранчевать и натягивать CI, это не взаимоисключающие, ИМХО, вещи
Я как-то читал про это дело, но в реале не использовал и не знаю, на сколько это будет удобно. Что, если кто-то уже заюзал мой feature код? Даже если проблема rollback будет решаться легко, как гарантировать, что это не приведет к проблемам? У меня слишком много вопросов. А если ты разрабатываешь в ветке и код никогда не был в мастере, то откатывать и не нужно.
@@programisli ну, подобные вопросы возникают про каждый из вариантов процесса разработки :) Я вот не представляю, как можно месяц сидеть в своей ветке, не подтягивая ничего из мастера, и потом не застрять на 2 дня на резолвинге конфликтов. Обычно если кто-то использует код, закрытый фиче-флагом, то его код тоже должен быть им же и закрыт, либо там тонкая заглушка, отбивающая переход к вызову фичи на входе. Роллбек, по факту, проверяется по ходу, так как из того же самого кода найтли-билды работают с включенными фиче-флагами, которые в процессе разработки, а релиз-кандидаты - с выключенными.
На мой взгляд если разработчикам необходимо постоянно следить за тем что делают другие, то есть проблема в архитектуре проекта, разбиении кодовой базы на файлы и в распределении задач между программистами. Могут быть процессы переезда с одной технологии на другую, где приходится вносить правки во многие файлы, но в таком случае внесение новых фич должно быть заблокировано на период переезда
Там же сказано в видео, что CI в данном случае не воспринимается как доставка приложения, а как принцип работы с кодом. CI/CD же состоит из двух процессов - CI - интеграция CD доставка. Так вот из этого процесса можно взять CI и работать только с кодом, постоянно интегрируя его
@@programisli Вы не понимаете, что такое ci. Нет нескольких трактований этого термина. Это вообще ни как не связано с работой в git, темболее с gitflow! Это абсолютно разные вещи! Просто у нас много людей, которые не понимают эти процессы. Они свой опыт выдают за единственную реалезацию. Они думают, что что-то понимают в этом, но они заблуждаются. CI это не коммиты в общую ветку. Это процесс через который проходит код до попадания на QA или любое другое окружение. Главная цель - это запуск тестов и проверка всего кода, а не по отдельным веткам. Вообщем не буду здесь освещать и объяснять. Просто изучите что это такое перед тем как об этом говорить или писать!
На большом проекте с грамотным менеджментом тяжело словить мердж конфликт, в спринт просто не возьмут две фичи которые сильно пересекаются. Да и CI можно настроить для всех веток, а не только для мастера
хорошее видео, заставило задуматься. Аж на 3 попытки написать "достойны" коммент хватило (это 4й). Понравились сравнения с машинами (канбан вспомнился) и рисованием, подумал что муралы рисует несколько людей и хорошо у них получается. Немного конечно получилось затянуто и в конце какой-то трешак (хз как назвать воду, карпов после рассказов про CI/CD и GitFlow), но наверное этот трешак и заставил меня написать коммент, хз даже... Но думал я об этом видео целый день) Короче мне кажется что в вашей истории CI используется отрывисто от контекста, т.е. там еще должно быть CD, которое должно доставлять это все конечным пользователям... Я наверное никогда не исползовал CI из этой концепции, а только CD, хотя хз как обозовать: при пуше тега деплоить в продакшен?! В целом делайте видео, чуть сжатее, будет лучше!
CI/CD недаром пишут вместе, потому что очень часто идут вместе, но в данном случае разговор был именно о CI с точки зрения кода. Я просто увидел видео одного американского специалиста, который как раз утверждает, что ветки это плохо и привёл хорошие доводы, которые имеют право на жизнь, но на мой взгляд они приносят больше проблем и записал своё мнение на эту тему
@@programisli целиком и полностью согласен, что подход с фича ветками и деплой ветками - самый лучший! Единственное с чем сталкивался - это разработка большого куска программы, например несколько эндпоинтов и их нужно распараллелить. Т.е. появляется общий код от которого все зависят и модифицируют его под себя ;( Как решение было делать одну фичу с основой, а только после приступать к остальным.
Спасибо за ваши мысли, Михаил. Вы в прошлых видео думали рассказывать про паттерны, не станете этого делать? А может пройтись по тем самым алгоритмам и тонко рассказать, как они работают. Просто ваш рассказ, очень ясен, ваш подход к рассказу, может объяснить многим вещи, которые они не могли понять из других источников
спасибо за видео, было очень интересно и полезно послушать. Не забрасывайте пожалуйста канал, ваши видео очень интересно смотреть - вы очень круто объясняете, для людей которые только вливаются в айти, ваши видео заходят на ура. Вы тот человек, который объясняет всё так что после просмотра ваших видео нет никаких вопросов. И спасибо за видео про карпа в конце, никогда раньше не видел чтоб эти тостячки так высоко пригали - у нас в речках они все ленивые :)
Мы используем тактику тестирования каждого Pull Request прежде, чем слить с мастером. Сделал изменение, отправил PR, прогнали тесты, слили. А так же используем только rebase.
Миша, не оставляй канал, у тебя один из самых крутых IT каналов в ru youtube. Просто все привыкли к контенту "c++ за час" и тому подобное. Я считаю что твой канал и канал SOER, люди обделяют вниманием потому что процентов 70% зрителя IT каналов это "Вайтишники". Скоро они все отработают по пол годика и научаться отличать полезный контент от сказочного, а пока держись и не сдавайся. С удовольствием смотрю все твои видео, удачи.
Спасибо, пока бросать не планирую, я просто ищу, как бы сделать его интересне, полезнее
@@programisli Было бы интересно послушать про архитектуру. Как писать код чисто, чтобы потом было меньше багов в итоге, либо как избегать таких ситуаций.
Честно говоря, вообще удивлен, что у кого-то есть такое представление о CI ) Видимо, сказывается опыт. Для меня CI - это просто автоматический запуск тестов (и других проверок) в системе контроля версий, чтобы не слить невалидный код в мастер ветку. Иными словами, CI мы используем не вместО, а вместЕ с ветвлением. Да и то, что кто-то, используя гит, не делает фича-веток, тоже звучит как новость из параллельной вселенной, если честно ) Но спасибо за то, что делитесь опытом!
Михаил, очень интересно вас слушать и смотреть, не закрывайте канал, пожалуйста.
Не планирую закрывать, я ищу, как его сделать лучше
дядь, продолжай! только подписался на тебя и не жалею!
Я за ветки, получаем всегда стабильный мастер, что для финтеха жизненно важно.
не оставляй канал!!!
GitFlow наше все
да не ci какая-то пижня. работаю по гитфлоу. иногда функционал нужно перенести в другой релиз и тогда ветка просто ждёт своей очереди на слияние. иногда разработка долгая в несколько сервисах.
3 дня на первый сервис, потом 3 дня на второй и ещё 3 на третий, в таком случае ci будет постоянно ломаться.
да и тестировщикам проще когда поведение в ветке ожидаемо, когда он тестирует определенную фичу.
если тестеровщик будет тестировать фичу в общей ветке, ему нужно еще как-то узнать о всех фичах доработках в общей ветке иначе будет миллион запросов: а почему это работает так, а почему тут теперь иное поведение и тд
Такое ещущение, что под CI тут имеется в виду trunk-based development (SVN-style), в моем понимании CI и GitFlow все-таки праллельные вещи. В общепринятом смысле CI вполне работает вместе с git flow (и очень хорошо). От trunk-based всегда бегу с ужасом - с ним больше проблем, чем бенефитов, с git flow же все атомарно, нормальная история, тесты гоняются после коммита во всех ветках, пожтому автора изначального посыла считаю не правым и скорее всего, если им плохо живется с ветками - есть какие-то проблемы в архитектуре приложения/бизнесс процессах и т.д
Только GIT Flow, причем оттестированный! Неоттестированный код в мастере это ЗЛО!
У нас на работе тоже мусорят прямо в мастер, не каждый код ревью способен увидеть баги, поэтому от молодых регулярно проскакивают косяки, ломающие сайт.
Git-flow, CI, feature и develop/master ветки, rebase/merge синхронизация с develop, staging/production окружения, unit/integration тесты, ручное тестирование каждой новой функции, регулярные релизы. Профит.
Так и не понял, почему нельзя при CI использовать бранчевание и поставку на стэйджинг где уже QA проводят приёмочное тестирование (а если надо, то и демо для кастомера). И всё это с регулярной актуализацией из мастера. И уже когда фича готова - она вмерживается к запланированной поставке в мастер. Более того, например, в вики про непрерывную интеграцию именно так и предлагают:
> эта проблема может решаться созданием отдельной «ветки» (англ. branch) проекта для внесения крупных изменений (код, разработка которого до работоспособного варианта займет несколько дней, но желательно более частое сохранение результата в репозиторий). По окончании разработки и индивидуального тестирования такой ветки, она может быть объединена (merge) с основным кодом
Если три программиста пишут в своих ветках и не интегрируют свой код в мастер, то они не видят изменений друг друга, поэтому сторонники постоянной интеграции рекомендуют мерджить в мастер как можно чаще
@@programisli Кто-то закончил фичу, вмержил в мастер, раскатал - остальные забрали из мастера и в этот момент вмержили свой код с итоговым вариантом, не тратя время на стопицот промежуточных решений и их мержи, с мержами, с мержами с предыдущими фичами и мержами мержей. При этом разработчик фичи лучше понимает как правильно свою фичу подмержить в основной код. А вот когда там параллельно копошится много человек (что уже само по себе несколько странно и напряжно), можно сойти с ума пока смержишься и тем более такое нельзя ставить на более-менее адекватном проекте в прод. И так проще разобраться, какая поставка сломала что-то.
В общем если более двух разработчиков - однозначно нужно бранчевать и натягивать CI, это не взаимоисключающие, ИМХО, вещи
! Давайте уточним.
1. Класс. В Канаде наверное хорошо. В Питере хорошо на скалах у российско-финской границы.
В Питере хорошо и красиво
19:24 Полностью согласен)))
А можно взять и заюзать фиче-флаги изначально. Тогда что-то заинтегрированное выпилить-отключить вообще элементарно
Я как-то читал про это дело, но в реале не использовал и не знаю, на сколько это будет удобно. Что, если кто-то уже заюзал мой feature код? Даже если проблема rollback будет решаться легко, как гарантировать, что это не приведет к проблемам? У меня слишком много вопросов. А если ты разрабатываешь в ветке и код никогда не был в мастере, то откатывать и не нужно.
@@programisli ну, подобные вопросы возникают про каждый из вариантов процесса разработки :) Я вот не представляю, как можно месяц сидеть в своей ветке, не подтягивая ничего из мастера, и потом не застрять на 2 дня на резолвинге конфликтов.
Обычно если кто-то использует код, закрытый фиче-флагом, то его код тоже должен быть им же и закрыт, либо там тонкая заглушка, отбивающая переход к вызову фичи на входе. Роллбек, по факту, проверяется по ходу, так как из того же самого кода найтли-билды работают с включенными фиче-флагами, которые в процессе разработки, а релиз-кандидаты - с выключенными.
Фиче флаги все-таки усложняют код, иногда их прямо реально сложно сделать.
А если нужно например переименовать\изменить поле в БД?
кажется что ci подходит для mvp или для проектов на самом старте пока не сделали первый релиз
На мой взгляд если разработчикам необходимо постоянно следить за тем что делают другие, то есть проблема в архитектуре проекта, разбиении кодовой базы на файлы и в распределении задач между программистами. Могут быть процессы переезда с одной технологии на другую, где приходится вносить правки во многие файлы, но в таком случае внесение новых фич должно быть заблокировано на период переезда
Топ!
Всегда коммитил в master, все чего-то злятся... :)
Ну вот мы и вычислили всеGITное зло :)
Помоемому Вы не понимаете, что такое ci/cd. Это не исключает работу в ветках. Просто нужно построить правильный процесс ci/cd
Там же сказано в видео, что CI в данном случае не воспринимается как доставка приложения, а как принцип работы с кодом. CI/CD же состоит из двух процессов - CI - интеграция CD доставка. Так вот из этого процесса можно взять CI и работать только с кодом, постоянно интегрируя его
@@programisli Вы не понимаете, что такое ci. Нет нескольких трактований этого термина. Это вообще ни как не связано с работой в git, темболее с gitflow!
Это абсолютно разные вещи!
Просто у нас много людей, которые не понимают эти процессы. Они свой опыт выдают за единственную реалезацию. Они думают, что что-то понимают в этом, но они заблуждаются.
CI это не коммиты в общую ветку. Это процесс через который проходит код до попадания на QA или любое другое окружение. Главная цель - это запуск тестов и проверка всего кода, а не по отдельным веткам.
Вообщем не буду здесь освещать и объяснять. Просто изучите что это такое перед тем как об этом говорить или писать!
я думаю що нада розбавляти ІТ контект з життям в Канаді
На большом проекте с грамотным менеджментом тяжело словить мердж конфликт, в спринт просто не возьмут две фичи которые сильно пересекаются. Да и CI можно настроить для всех веток, а не только для мастера
Плжсую за ветки
хорошее видео, заставило задуматься. Аж на 3 попытки написать "достойны" коммент хватило (это 4й).
Понравились сравнения с машинами (канбан вспомнился) и рисованием, подумал что муралы рисует несколько людей и хорошо у них получается.
Немного конечно получилось затянуто и в конце какой-то трешак (хз как назвать воду, карпов после рассказов про CI/CD и GitFlow), но наверное этот трешак и заставил меня написать коммент, хз даже... Но думал я об этом видео целый день)
Короче мне кажется что в вашей истории CI используется отрывисто от контекста, т.е. там еще должно быть CD, которое должно доставлять это все конечным пользователям... Я наверное никогда не исползовал CI из этой концепции, а только CD, хотя хз как обозовать: при пуше тега деплоить в продакшен?!
В целом делайте видео, чуть сжатее, будет лучше!
CI/CD недаром пишут вместе, потому что очень часто идут вместе, но в данном случае разговор был именно о CI с точки зрения кода. Я просто увидел видео одного американского специалиста, который как раз утверждает, что ветки это плохо и привёл хорошие доводы, которые имеют право на жизнь, но на мой взгляд они приносят больше проблем и записал своё мнение на эту тему
@@programisli целиком и полностью согласен, что подход с фича ветками и деплой ветками - самый лучший!
Единственное с чем сталкивался - это разработка большого куска программы, например несколько эндпоинтов и их нужно распараллелить. Т.е. появляется общий код от которого все зависят и модифицируют его под себя ;( Как решение было делать одну фичу с основой, а только после приступать к остальным.
Спасибо за ваши мысли, Михаил.
Вы в прошлых видео думали рассказывать про паттерны, не станете этого делать?
А может пройтись по тем самым алгоритмам и тонко рассказать, как они работают.
Просто ваш рассказ, очень ясен, ваш подход к рассказу, может объяснить многим вещи, которые они не могли понять из других источников
Надо подумать, если я точно смогу увидеть, что у меня получиться по другому и лучше, то можно будет.
спасибо за видео, было очень интересно и полезно послушать.
Не забрасывайте пожалуйста канал, ваши видео очень интересно смотреть - вы очень круто объясняете, для людей которые только вливаются в айти, ваши видео заходят на ура. Вы тот человек, который объясняет всё так что после просмотра ваших видео нет никаких вопросов.
И спасибо за видео про карпа в конце, никогда раньше не видел чтоб эти тостячки так высоко пригали - у нас в речках они все ленивые :)
В конце этого видео настоящая рыбалка ua-cam.com/video/fCqbzFI_8_I/v-deo.html это было в прошлом году в сентябре
Канал топ! Нужно оставлять)
Спасибо, оставим
Гит флоу. Канал не бросай.
Я брал неделю отдыха, на этой неделе еще будет минимум два видео на втором канале. Бросать не планирую, но все думаю, как сделать его лучше
Мы используем тактику тестирования каждого Pull Request прежде, чем слить с мастером. Сделал изменение, отправил PR, прогнали тесты, слили.
А так же используем только rebase.
Первый!!!
Куда ты раньше бати то?!
@@Edvard-Aliev молод для моего бати :)