@@user-fm7jl3ll9n есть такой ютубер-стример травоман по доте 2 и он похож на этого чела, и его целью было улучшать коммюнити играя на бесячем герое того времени (течис)
Спасибо! Более грамотного и доступного объяснения я не нашел! Желаю тебе развития и процветания. Вроде бы и простую вещь объяснил, а понятно для новичков объяснить только ты смог)
То чувство, когда больше 5 лет работаешь по процессу, а потом узнаешь, что он называется модным словом CI/CD. А видос простой для понимания и познавательный. Круто
Спасибо вам.Просто о сложном.Я -ручной тестировщик,пытаюсь набраться знаний,чтобы перейти в автоматизаторы на Python,чтобы найти новую работу,так как сейчас я только ручник. Уже немного умею писать автотесты для API и WEB.А вот CI/CD для меня темная лошадка.Теперь стало немного проще.Спасибо вам за уроки.
Как же Вы здорово объясняете! Можно Вас попросить сделать практичный подробный видос про Git / Github где Вы также простыми словами понятно объясняете всю суть и показываете реальные кейсы. Интересно увидеть как Вы - загружаете Ваш проект на Гитхаб из Вашей IDE (возможно разными способами). - как подключаете SSH - как мерджите, пушите и тд - как работаете в терминале (разные команды) - rebase / cherry и тд
На реальном проекте dev никогда не мержится в main :) В дев что только не валят, потом создается релезная ветка (еще наверняка с фичетоглами), тестировщики тестируют фичи своей команды, потом делают регресс тест и только после этого релейная ветка уходит в main и пользователи радуются новым фичам :)
Прикольная тема, щас на работе как раз этим на нескольких проектах занимаюсь, причём у нас используется bitbucket и когда я начинал, никто ничего не объяснял да и туториалов нормальных по битбакету нет, так что думаю всем полезно будет эту тему изучить. Спасибо за видос)
Здравствуйте! Большое спасибо за ваше полезное видео! У меня возник вопрос, который, думаю, будет интересен многим. Не могли бы вы рассказать о том, как правильно откатывать доработки (фичи), которые не прошли тестирование при использовании CI/CD? Какие существуют лучшие практики для минимизации рисков и ошибок в этом процессе? Очень хотелось бы увидеть ваше мнение и рекомендации по этой теме. Спасибо!
Общее объяснение отличное, единственно я не могу прикинуть как бы я это понял если бы увидел это видео до того как начал работу в моей команде (команда очень сильная), так-то сейчас смотрю и кажется, что всё прям очень понятно и легко )
Я так до конца и не понял. Docker это приложение упакованое как бы в архив, типа ZIP, RAR и т. д., которое потом запускается на сервере, облаке и т.д.? Спасибо.
Спасибо за видео. очень круто все рассказал, остался не совсем понятный этап. ты говорил про релизы, что там собираются несколько изменений, а как они запускаются, если сделав слияние ты уже развернул это на тестовом контуре. ну допустим 2 программиста написали по фиче, но исходя из предоставленного примера, они никак не собирают релиз, а сразу развертывают это.
я предпочитаю dev ветку называть main, который потом пушиться в ветку production. Это облегчает DX, например при создании PR в гитхабе он автоматически целиться в main, а так как мы туда ничего пушить не собираемся, то каждый раз придётся менять на dev ветку.
В моей компании нет dev, все происходило на прямую в main (т.к. проект начинался с 0 и соответственно нет надобности создавать отдельное окружение для тестирования). Как только проект завершат, тогда реализуют dev
«сервер, где запущено приложение и где погоняются все эти сборки - это один сервер» «и это нормально». Д.б… Это преступление даже для небольшой компании/проекта и полный идиотизм!.. выстрел себе в ногу. Офигенный спец. Спасибо, что ты есть. Остальное (кроме еще веток и кто что куда мержит) прокатит. Включая Selectel.
Я думаю, если работает достаточно большая команда разработчиков (больше 4-5 человек), то да. Но чаще всего сборкан на dev ломается, если есть какой-то мелкий баг. Тогда он быстро фиксится и "домерживается" в dev
На больших, нормальных проектах не получится сделать мердж в основную ветку с ошибками в СІ. Там СІ работает так что когда открываеться мердже реквест, СІ имитирует мердж и проганяет все проверки на результате имитации мерджа (будто мердж реквест уже смерджован на основную ветку), и если СІ не проходит - мердж заблокирован.
@@artemshumeiko У нас, из того что вижу в коде - каждый раз создается пустая база на которой применяется призма резет (чистит + применяет заново все миграции) и потом летят тесты, билды и т.д. Не уверен почему не используем копию БД, завтра спрошу у ребят.
Баги. Так как на практике программисту срать, чё он написал, тестировщик не делает полную проверку (нет времени, а его автотесты - кусок говна), code review проведено на отъ***сь, т.к. Senior тусит где-нибудь в клубе, а баг всплывает в 3 часа ночи у Заказчика, который пишет тикет в техподдержку. Техподдержка неделю молчит, ничего не делая с тикетом, а потом руководство Заказчика идёт к менеджеру проекта с матами! В итоге МП сам ищет и отлавливает баг, его же детально описывает в задаче и сам всё тестирует🤣
Привет, большой респект за видео. Скажи а есть ли у тебя видео по редакторам? Я сам использую Visual Studio Code но знаю есть много других крутых, такие как jetbrains и твой сегодняшний. хотелось бы решить для себя
Мне не понятно что там за тесты, по прошествии которых галочки ставятся? Это другие люди должны что-то сделать, или оно само что-то проверяет? И если оно само, то что это?
Эти тесты были написаны разработчиками, они прогоняются полностью каждый раз при новом коммите, чтобы убедиться, что все работает. Тесты прогоняются автоматически на CI сервере (про сервер рассказывал в видео)
В реальной практике конечно такое редко встречается, если говорить про релиз (cd), если говорить про обновление релизом продакшен контура (там где реальные пользователи). Обычно это не происходит автоматически по мерджу в основную ветку, а отдается протестированный билд (сборка) в виде докер образа с определенным номером команде девопсов - это те которые разворчаивают новый релиз на прод серверах. Причина этому в том что прод доступен малому числу людей со специальными правами. Если это банк то зачастую только команде девопсов от банка. Также разработка может вестись разработчиками с других компаний - аутсорсинг, и тогда также возможно что прод (основной сервер с приложением для реальных пользователей) может быть доступен только заказчику, а аутсорс команды передают им готовые релизные билды
а сколько время простоя при деплое новых контейнеров? По идее еще надо настраивать реплики, чтобы старые контейнеры не умерли, пока новые полностью не запустятся
@@artemshumeiko в сварме тоже нет, если настроить, у меня автодеплой бывает занимает минут по 20 на 4 этапа, а время простоя (когда приложение не отвечает пользователям) полсекунды )) конечно в к8с это было бы проще настраивать, но я его ни разу не использовал, как-то вот не попадался он мне в проектах )
Очень поверхностно - совсем для новичков, но общее представление дает. Забавно, что всего 2 стенда, но есть тесты :) Обычно стендов намного больше - dev, ift, psi, preprod, prod, ну и в нормальных компаниях, чтобы ветку main или master после мерджа залить в прод, не практикуют. Только через запросы на изменения с указанием версии. А так ну максимум она на preprod уедет, если настроено :)
Во мне кипит гнев и негодование. CI/CD это не про сборку и развертывания. Это про непрерывный процесс улучшения продукта. Т.е каждый день вносятся изменения в продукт и каждый день выкатываються изменения. Это про совокупность процессов. Про то как улучшать и экспериментировать каждый день
@@abraham3345 когда ты приедешь устраиваться на работу и тебя спросят как ты будешь реализовать CI/CD процессы. Собес завершится через 5 секунд после того как ты начнешь рассказывать что то из этого видео
Есть 2 книги. Первая называется Continuous Integration (CI) вторая называется Continuous Delivery (CD) этих двух книг достаточно чтобы разобраться что такое CI/CD и вы удивитесь прочитав их…
Вроде и да и вроде и нет. При таком объяснении ускользает суть пула потоков при асинхронном программировании. Он не просто один и не ждёт. Управление передаётся другим задачам пока идёт ожидание завершения уже запущенных. Под каждую новую задачу (обычно задача = новое подключение) выделяется новый поток и он выполняется до тех пор, пока не встретит I\O -bound задачу. Когда поток её встречает и начинает "ждать", этот поток как бы передаётся под новую задачу. Когда ответ буде получен эта задача будет готова выполняться дальше, как только под неё выделят какой-нибудь поток, освободившийся в других задачах.
Дарова мужик. Видео посмотрел. Можешь не удалять, вдруг еще кому то полезно или интересно будет посмотреть. Такой вопрос неожиданный к тебе - ты девопс?
На больших, нормальных проектах не получится сделать мердж в основную ветку с ошибками в СІ. Там СІ работает так что когда открываеться мердже реквест, СІ имитирует мердж и проганяет все проверки на результате имитации мерджа (будто мердж реквест уже смерджован на основную ветку), и если СІ не проходит - мердж заблокирован.
Приглашаю на мой Практический курс по Backend разработке по всем актуальным технологиям: artemshumeiko.ru
Респект Травоману за то что помимо стримов улучшает комьюнити программистов !
ахпахпахпахпахпахпахпа,божееее,чел ты гений просто
ХААХАХХАХАХАХА
Бригаду сюда
ahahahahahah
@@user-fm7jl3ll9n есть такой ютубер-стример травоман по доте 2 и он похож на этого чела, и его целью было улучшать коммюнити играя на бесячем герое того времени (течис)
Хорошая подача, грамотная речь, доступное объяснение. Теперь ждем продробный разбор с примерами кода самого пайплайна.
Классная подача, чистая речь, умение доносить мысль! Спасибо вам!
Лайк и подписка
ОЧЕНЬ сильно ждем практику
Спасибо! Более грамотного и доступного объяснения я не нашел! Желаю тебе развития и процветания. Вроде бы и простую вещь объяснил, а понятно для новичков объяснить только ты смог)
То чувство, когда больше 5 лет работаешь по процессу, а потом узнаешь, что он называется модным словом CI/CD.
А видос простой для понимания и познавательный.
Круто
Спасибо вам.Просто о сложном.Я -ручной тестировщик,пытаюсь набраться знаний,чтобы перейти в автоматизаторы на Python,чтобы найти новую работу,так как сейчас я только ручник. Уже немного умею писать автотесты для API и WEB.А вот CI/CD для меня темная лошадка.Теперь стало немного проще.Спасибо вам за уроки.
На мой взгляд, самое очевидное и понятное объяснение сложного и многосоставного процесса
Артём, очень круто получилось! Продолжай так же 🎉
Нам такой контент нравится)
Как же Вы здорово объясняете! Можно Вас попросить сделать практичный подробный видос про Git / Github где Вы также простыми словами понятно объясняете всю суть и показываете реальные кейсы. Интересно увидеть как Вы
- загружаете Ваш проект на Гитхаб из Вашей IDE (возможно разными способами).
- как подключаете SSH
- как мерджите, пушите и тд
- как работаете в терминале (разные команды)
- rebase / cherry и тд
к сожалению, такое можно познать только на практике, ищите проект и единомышленников, создавайте репозиторий и практикуйтесь
На реальном проекте dev никогда не мержится в main :)
В дев что только не валят, потом создается релезная ветка (еще наверняка с фичетоглами), тестировщики тестируют фичи своей команды, потом делают регресс тест и только после этого релейная ветка уходит в main и пользователи радуются новым фичам :)
Rc1…rc2…
Прикольная тема, щас на работе как раз этим на нескольких проектах занимаюсь, причём у нас используется bitbucket и когда я начинал, никто ничего не объяснял да и туториалов нормальных по битбакету нет, так что думаю всем полезно будет эту тему изучить. Спасибо за видос)
Круто, круто. Примерил инфу на свой текущий проект. По полочкам удалось свои текущие знания разложить
спасибо, наконец-то хоть кто-то понятно объяснил )
Про необходимость знания ci/cd вы в точку. Сейчас в резюме есть требование хотя бы к пониманию процессов ci cd
Артём, большое спасибо, объяснение - мощь 👍💪
Очень хорошо объясняете, спасибо вам огромное. Простым языком объяснили человеку без профильного образования, работающего в этой сфере 2 месяца)
Приятная подача, лайк заслужен!)
Очень доступно и интересно! Артём, спасибо👍
Дулаю с 0 приложение без знаний программирования, эти знания мне очень помогут не сломать уже готовый прод, когда буду фиксить баги)) Спасибо)
Здравствуйте! Большое спасибо за ваше полезное видео! У меня возник вопрос, который, думаю, будет интересен многим. Не могли бы вы рассказать о том, как правильно откатывать доработки (фичи), которые не прошли тестирование при использовании CI/CD? Какие существуют лучшие практики для минимизации рисков и ошибок в этом процессе? Очень хотелось бы увидеть ваше мнение и рекомендации по этой теме. Спасибо!
Отличная подача. Продолжай, а мы ждем новых видео!
Общее объяснение отличное, единственно я не могу прикинуть как бы я это понял если бы увидел это видео до того как начал работу в моей команде (команда очень сильная), так-то сейчас смотрю и кажется, что всё прям очень понятно и легко )
Реально очень крутая подача. Все по полочкам 👍
Очень понятное объяснение даже для меня, психолога. Поскольку работаю в основном с айтишниками, приходится быть в теме.😊
Объясняешь им что такое ci/CD , да ?
Наконец-то!!!! Хоть кто-то!!!! Доступно и понятно все обьяснил!!!! СПАСИБО!!!
спасибо)
очень классная подача. разобрался с первого раза⚡️
Хорошее видео, доступно объясняет тему. Подписался, жду вторую часть
Спасибо большое за понятное пояснение. Держи ❤
Прикольно, сочно рассказываешь. Чувствуется заинтересованность а не как обычно у всех - рассказ ради рассказа
Все понятно и кратко. Лайк в поддержку канала.
Спасибо! Очень информативно и не перегружает.
Качественный контент. Приятно смотреть. Спасибо Артем. 🤝
Ждём продолжения. Очень актуальная тема. Хотелось бы узнать как это чудо настроить.
AC\DC лучше
Не умничай, а сноси путина.
От души братик, ждем вторую часть)
Я так до конца и не понял. Docker это приложение упакованое как бы в архив, типа ZIP, RAR и т. д., которое потом запускается на сервере, облаке и т.д.?
Спасибо.
Артем, спасибо. отличный канал, много полезной инфы!
Супер !) Особенно понравилось "Разработчик пишет код и вроде у него всё даже работает"😂
Подписалась после первой фразы;))))👍🏻
Спасибо за видео. очень круто все рассказал, остался не совсем понятный этап. ты говорил про релизы, что там собираются несколько изменений, а как они запускаются, если сделав слияние ты уже развернул это на тестовом контуре. ну допустим 2 программиста написали по фиче, но исходя из предоставленного примера, они никак не собирают релиз, а сразу развертывают это.
Мне даже как геймдев плюсовику полезно было, спасибо)
ХАРОШ
Продолжай развертывать 👍
Искала медь, нашла золото! Спасибо!)
Конешно же селектел 🥰 спасибо ребята , что вы работаете 👨💻
теория понятна, жду вторую версию
Классный видос, спасибо!
Спасибо. Очень доходчиво рассказано
a=int(input('Введите число: ', ))
b=int(input('Введите число: ', ))
c=int(input('Введите число: ',))
if a>b:
maximum=a
else:
maximum=b
if c>maximum:
maximum=c
print('Максимальное число лайков Артёму:' , maximum)
print('Спасибо за подобное видео')
Спасибо за труд
Только сегодня смотрел деплой, ждал CI/CD, а оно вон как :)
Лайк подписка. Еще бы как настроить видос был, было бы вообще круто🔥
В понедельник выйдет видео с настройкой)
я предпочитаю dev ветку называть main, который потом пушиться в ветку production. Это облегчает DX, например при создании PR в гитхабе он автоматически целиться в main, а так как мы туда ничего пушить не собираемся, то каждый раз придётся менять на dev ветку.
просто делаешь ветку dev дефолтной и таких проблем не возникает)
11:08 может наоборот Е на Ё? Или русский язык уже всё... ой, то есть все?
Внатуре четко! Улыба от Братвы!
Артем, жду с нетерпением пример реализации пайплайна от тебя, желательно с применением Jenkins and SonarQube
Как происходит автоматическая и автоматизированная перестройка серверов на то, чтобы выдавать страницу с изменениями?
Реально, стало более понятно, спасибо :)
Спасибо за объяснение!
Зачем пайплайне этап cleanup с удалением старых контейнеров? как будет откат происходить без старых образов?
это простая реализация ci/cd
Вообще супер видео
В моей компании нет dev, все происходило на прямую в main (т.к. проект начинался с 0 и соответственно нет надобности создавать отдельное окружение для тестирования). Как только проект завершат, тогда реализуют dev
«сервер, где запущено приложение и где погоняются все эти сборки - это один сервер» «и это нормально». Д.б… Это преступление даже для небольшой компании/проекта и полный идиотизм!.. выстрел себе в ногу. Офигенный спец.
Спасибо, что ты есть.
Остальное (кроме еще веток и кто что куда мержит) прокатит. Включая Selectel.
Привет. Не нашел ни в описании, ни в комментах сервис с помощью которого ты демонстрируешь схемы. Можешь сказать его название?
Miro
В случае если мердж реквеств в дев апрувнули и код не прошел тесты, откатывается ли дев?
Я думаю, если работает достаточно большая команда разработчиков (больше 4-5 человек), то да.
Но чаще всего сборкан на dev ломается, если есть какой-то мелкий баг. Тогда он быстро фиксится и "домерживается" в dev
На больших, нормальных проектах не получится сделать мердж в основную ветку с ошибками в СІ. Там СІ работает так что когда открываеться мердже реквест, СІ имитирует мердж и проганяет все проверки на результате имитации мерджа (будто мердж реквест уже смерджован на основную ветку), и если СІ не проходит - мердж заблокирован.
@@someDude1368 как с миграциями работают в данном случае? Под каждый MR создается копия dev базы и на ней прогоняются миграции?
@@artemshumeiko У нас, из того что вижу в коде - каждый раз создается пустая база на которой применяется призма резет (чистит + применяет заново все миграции) и потом летят тесты, билды и т.д. Не уверен почему не используем копию БД, завтра спрошу у ребят.
Continuous а не Continuos, но обяснение хорошее
Используют ли кубер на dev ветках, если в проде он есть?
да
Какую программу используете для демонстрации схемы? Ищем сейчас аналог миро)
Miro
Тогда что в мастере? С точки зрения CD?
Баги. Так как на практике программисту срать, чё он написал, тестировщик не делает полную проверку (нет времени, а его автотесты - кусок говна), code review проведено на отъ***сь, т.к. Senior тусит где-нибудь в клубе, а баг всплывает в 3 часа ночи у Заказчика, который пишет тикет в техподдержку. Техподдержка неделю молчит, ничего не делая с тикетом, а потом руководство Заказчика идёт к менеджеру проекта с матами! В итоге МП сам ищет и отлавливает баг, его же детально описывает в задаче и сам всё тестирует🤣
красивые дизайн и анимации у видео! где учились?
Привет, большой респект за видео. Скажи а есть ли у тебя видео по редакторам? Я сам использую Visual Studio Code но знаю есть много других крутых, такие как jetbrains и твой сегодняшний. хотелось бы решить для себя
Воооу контент подьехал
Мне не понятно что там за тесты, по прошествии которых галочки ставятся? Это другие люди должны что-то сделать, или оно само что-то проверяет? И если оно само, то что это?
Эти тесты были написаны разработчиками, они прогоняются полностью каждый раз при новом коммите, чтобы убедиться, что все работает. Тесты прогоняются автоматически на CI сервере (про сервер рассказывал в видео)
это мировые программисты должны проверить и галочку поставить
В реальной практике конечно такое редко встречается, если говорить про релиз (cd), если говорить про обновление релизом продакшен контура (там где реальные пользователи). Обычно это не происходит автоматически по мерджу в основную ветку, а отдается протестированный билд (сборка) в виде докер образа с определенным номером команде девопсов - это те которые разворчаивают новый релиз на прод серверах. Причина этому в том что прод доступен малому числу людей со специальными правами. Если это банк то зачастую только команде девопсов от банка. Также разработка может вестись разработчиками с других компаний - аутсорсинг, и тогда также возможно что прод (основной сервер с приложением для реальных пользователей) может быть доступен только заказчику, а аутсорс команды передают им готовые релизные билды
По факту
Ура! Спасибо большое за такой видос! Пишем комментарии о том, что хотите увидеть и вас услышат как и меня ❤
хочется больше примеров кода 🥹
в следующем видео напишем свой CI/CD 😎
а сколько время простоя при деплое новых контейнеров? По идее еще надо настраивать реплики, чтобы старые контейнеры не умерли, пока новые полностью не запустятся
зависит от скорости загрузки контейнера
на моем проекте простой занимает 1-2 секунды
Если говорим про кубер, там простоя нет
@@artemshumeiko в сварме тоже нет, если настроить, у меня автодеплой бывает занимает минут по 20 на 4 этапа, а время простоя (когда приложение не отвечает пользователям) полсекунды ))
конечно в к8с это было бы проще настраивать, но я его ни разу не использовал, как-то вот не попадался он мне в проектах )
Oчень круто !
Очень поверхностно - совсем для новичков, но общее представление дает. Забавно, что всего 2 стенда, но есть тесты :) Обычно стендов намного больше - dev, ift, psi, preprod, prod, ну и в нормальных компаниях, чтобы ветку main или master после мерджа залить в прод, не практикуют. Только через запросы на изменения с указанием версии. А так ну максимум она на preprod уедет, если настроено :)
Лучший, спс ❤
а как же этапы до сборки ? статический анализ кода? юнит тесты ? это очень важные этапы CI
Делать CI/CD для одной буквы в HTML. Вот это уровень :)
А как можно автоматически затестить что стили не посыпались и не поехали?
Идеальный пример на практике. Осталось понять чем занимает devops инженер и на каком этапе
Запаковывает коробочки😂😂😂
Он как белый господин на поле, следит чтобы все работало/работали 😂
Шик!
Точно, после сборки в текст.
Во мне кипит гнев и негодование. CI/CD это не про сборку и развертывания. Это про непрерывный процесс улучшения продукта. Т.е каждый день вносятся изменения в продукт и каждый день выкатываються изменения. Это про совокупность процессов. Про то как улучшать и экспериментировать каждый день
улучшение продукта - это коммит в репозиторий
CI/CD про сборку, тестирование и развертывание
@@artemshumeiko серьезно? Т.е если мы уберем CI/CD платформу то у нас ничего не получится? Мы не сможем собирать, тестировать и развертывать продукт?
@@abraham3345 когда ты приедешь устраиваться на работу и тебя спросят как ты будешь реализовать CI/CD процессы. Собес завершится через 5 секунд после того как ты начнешь рассказывать что то из этого видео
Есть 2 книги. Первая называется Continuous Integration (CI) вторая называется Continuous Delivery (CD) этих двух книг достаточно чтобы разобраться что такое CI/CD и вы удивитесь прочитав их…
я удивлюсь, если кто-то в 2024 изучает devops по книжкам
Нет нужна ещё книга "/" как минимум
Спасибо большое
Вроде и да и вроде и нет. При таком объяснении ускользает суть пула потоков при асинхронном программировании. Он не просто один и не ждёт. Управление передаётся другим задачам пока идёт ожидание завершения уже запущенных. Под каждую новую задачу (обычно задача = новое подключение) выделяется новый поток и он выполняется до тех пор, пока не встретит I\O -bound задачу. Когда поток её встречает и начинает "ждать", этот поток как бы передаётся под новую задачу. Когда ответ буде получен эта задача будет готова выполняться дальше, как только под неё выделят какой-нибудь поток, освободившийся в других задачах.
осталось рассказать как именно настраивать пайплайн ))
супер, спасибо
сделай видос про кафку пж
Скоро будет по брокерам!!)
Дарова мужик. Видео посмотрел. Можешь не удалять, вдруг еще кому то полезно или интересно будет посмотреть.
Такой вопрос неожиданный к тебе - ты девопс?
На больших, нормальных проектах не получится сделать мердж в основную ветку с ошибками в СІ. Там СІ работает так что когда открываеться мердже реквест, СІ имитирует мердж и проганяет все проверки на результате имитации мерджа (будто мердж реквест уже смерджован на основную ветку), и если СІ не проходит - мердж заблокирован.
Перед созданием ветки dev лучше бы сделать git pull)
Я девопс, тоже доводилось кхем,кхем, сталкиваться :D
Я бы сказал так Простое сделаем сложным
🔥🔥🔥
Нраица. Лукас выставлен.
Лови лайк!