@@user-fm7jl3ll9n есть такой ютубер-стример травоман по доте 2 и он похож на этого чела, и его целью было улучшать коммюнити играя на бесячем герое того времени (течис)
Как же Вы здорово объясняете! Можно Вас попросить сделать практичный подробный видос про Git / Github где Вы также простыми словами понятно объясняете всю суть и показываете реальные кейсы. Интересно увидеть как Вы - загружаете Ваш проект на Гитхаб из Вашей IDE (возможно разными способами). - как подключаете SSH - как мерджите, пушите и тд - как работаете в терминале (разные команды) - rebase / cherry и тд
То чувство, когда больше 5 лет работаешь по процессу, а потом узнаешь, что он называется модным словом CI/CD. А видос простой для понимания и познавательный. Круто
Спасибо вам.Просто о сложном.Я -ручной тестировщик,пытаюсь набраться знаний,чтобы перейти в автоматизаторы на Python,чтобы найти новую работу,так как сейчас я только ручник. Уже немного умею писать автотесты для API и WEB.А вот CI/CD для меня темная лошадка.Теперь стало немного проще.Спасибо вам за уроки.
Здравствуйте! Большое спасибо за ваше полезное видео! У меня возник вопрос, который, думаю, будет интересен многим. Не могли бы вы рассказать о том, как правильно откатывать доработки (фичи), которые не прошли тестирование при использовании CI/CD? Какие существуют лучшие практики для минимизации рисков и ошибок в этом процессе? Очень хотелось бы увидеть ваше мнение и рекомендации по этой теме. Спасибо!
Спасибо! Более грамотного и доступного объяснения я не нашел! Желаю тебе развития и процветания. Вроде бы и простую вещь объяснил, а понятно для новичков объяснить только ты смог)
На реальном проекте dev никогда не мержится в main :) В дев что только не валят, потом создается релезная ветка (еще наверняка с фичетоглами), тестировщики тестируют фичи своей команды, потом делают регресс тест и только после этого релейная ветка уходит в main и пользователи радуются новым фичам :)
Прикольная тема, щас на работе как раз этим на нескольких проектах занимаюсь, причём у нас используется bitbucket и когда я начинал, никто ничего не объяснял да и туториалов нормальных по битбакету нет, так что думаю всем полезно будет эту тему изучить. Спасибо за видос)
Общее объяснение отличное, единственно я не могу прикинуть как бы я это понял если бы увидел это видео до того как начал работу в моей команде (команда очень сильная), так-то сейчас смотрю и кажется, что всё прям очень понятно и легко )
Спасибо за видео. очень круто все рассказал, остался не совсем понятный этап. ты говорил про релизы, что там собираются несколько изменений, а как они запускаются, если сделав слияние ты уже развернул это на тестовом контуре. ну допустим 2 программиста написали по фиче, но исходя из предоставленного примера, они никак не собирают релиз, а сразу развертывают это.
В реальной практике конечно такое редко встречается, если говорить про релиз (cd), если говорить про обновление релизом продакшен контура (там где реальные пользователи). Обычно это не происходит автоматически по мерджу в основную ветку, а отдается протестированный билд (сборка) в виде докер образа с определенным номером команде девопсов - это те которые разворчаивают новый релиз на прод серверах. Причина этому в том что прод доступен малому числу людей со специальными правами. Если это банк то зачастую только команде девопсов от банка. Также разработка может вестись разработчиками с других компаний - аутсорсинг, и тогда также возможно что прод (основной сервер с приложением для реальных пользователей) может быть доступен только заказчику, а аутсорс команды передают им готовые релизные билды
Привет, большой респект за видео. Скажи а есть ли у тебя видео по редакторам? Я сам использую Visual Studio Code но знаю есть много других крутых, такие как jetbrains и твой сегодняшний. хотелось бы решить для себя
Во мне кипит гнев и негодование. CI/CD это не про сборку и развертывания. Это про непрерывный процесс улучшения продукта. Т.е каждый день вносятся изменения в продукт и каждый день выкатываються изменения. Это про совокупность процессов. Про то как улучшать и экспериментировать каждый день
@@abraham3345 когда ты приедешь устраиваться на работу и тебя спросят как ты будешь реализовать CI/CD процессы. Собес завершится через 5 секунд после того как ты начнешь рассказывать что то из этого видео
Очень поверхностно - совсем для новичков, но общее представление дает. Забавно, что всего 2 стенда, но есть тесты :) Обычно стендов намного больше - dev, ift, psi, preprod, prod, ну и в нормальных компаниях, чтобы ветку main или master после мерджа залить в прод, не практикуют. Только через запросы на изменения с указанием версии. А так ну максимум она на preprod уедет, если настроено :)
Есть 2 книги. Первая называется Continuous Integration (CI) вторая называется Continuous Delivery (CD) этих двух книг достаточно чтобы разобраться что такое CI/CD и вы удивитесь прочитав их…
Вроде и да и вроде и нет. При таком объяснении ускользает суть пула потоков при асинхронном программировании. Он не просто один и не ждёт. Управление передаётся другим задачам пока идёт ожидание завершения уже запущенных. Под каждую новую задачу (обычно задача = новое подключение) выделяется новый поток и он выполняется до тех пор, пока не встретит I\O -bound задачу. Когда поток её встречает и начинает "ждать", этот поток как бы передаётся под новую задачу. Когда ответ буде получен эта задача будет готова выполняться дальше, как только под неё выделят какой-нибудь поток, освободившийся в других задачах.
В моей компании нет dev, все происходило на прямую в main (т.к. проект начинался с 0 и соответственно нет надобности создавать отдельное окружение для тестирования). Как только проект завершат, тогда реализуют dev
Дарова мужик. Видео посмотрел. Можешь не удалять, вдруг еще кому то полезно или интересно будет посмотреть. Такой вопрос неожиданный к тебе - ты девопс?
а сколько время простоя при деплое новых контейнеров? По идее еще надо настраивать реплики, чтобы старые контейнеры не умерли, пока новые полностью не запустятся
@@artemshumeiko в сварме тоже нет, если настроить, у меня автодеплой бывает занимает минут по 20 на 4 этапа, а время простоя (когда приложение не отвечает пользователям) полсекунды )) конечно в к8с это было бы проще настраивать, но я его ни разу не использовал, как-то вот не попадался он мне в проектах )
Баги. Так как на практике программисту срать, чё он написал, тестировщик не делает полную проверку (нет времени, а его автотесты - кусок говна), code review проведено на отъ***сь, т.к. Senior тусит где-нибудь в клубе, а баг всплывает в 3 часа ночи у Заказчика, который пишет тикет в техподдержку. Техподдержка неделю молчит, ничего не делая с тикетом, а потом руководство Заказчика идёт к менеджеру проекта с матами! В итоге МП сам ищет и отлавливает баг, его же детально описывает в задаче и сам всё тестирует🤣
Я думаю, если работает достаточно большая команда разработчиков (больше 4-5 человек), то да. Но чаще всего сборкан на dev ломается, если есть какой-то мелкий баг. Тогда он быстро фиксится и "домерживается" в dev
На больших, нормальных проектах не получится сделать мердж в основную ветку с ошибками в СІ. Там СІ работает так что когда открываеться мердже реквест, СІ имитирует мердж и проганяет все проверки на результате имитации мерджа (будто мердж реквест уже смерджован на основную ветку), и если СІ не проходит - мердж заблокирован.
@@artemshumeiko У нас, из того что вижу в коде - каждый раз создается пустая база на которой применяется призма резет (чистит + применяет заново все миграции) и потом летят тесты, билды и т.д. Не уверен почему не используем копию БД, завтра спрошу у ребят.
Мне не понятно что там за тесты, по прошествии которых галочки ставятся? Это другие люди должны что-то сделать, или оно само что-то проверяет? И если оно само, то что это?
Эти тесты были написаны разработчиками, они прогоняются полностью каждый раз при новом коммите, чтобы убедиться, что все работает. Тесты прогоняются автоматически на CI сервере (про сервер рассказывал в видео)
На больших, нормальных проектах не получится сделать мердж в основную ветку с ошибками в СІ. Там СІ работает так что когда открываеться мердже реквест, СІ имитирует мердж и проганяет все проверки на результате имитации мерджа (будто мердж реквест уже смерджован на основную ветку), и если СІ не проходит - мердж заблокирован.
Приглашаю на мой Практический курс по Backend разработке по всем актуальным технологиям: artemshumeiko.ru
Респект Травоману за то что помимо стримов улучшает комьюнити программистов !
ахпахпахпахпахпахпахпа,божееее,чел ты гений просто
ХААХАХХАХАХАХА
Бригаду сюда
ahahahahahah
@@user-fm7jl3ll9n есть такой ютубер-стример травоман по доте 2 и он похож на этого чела, и его целью было улучшать коммюнити играя на бесячем герое того времени (течис)
Хорошая подача, грамотная речь, доступное объяснение. Теперь ждем продробный разбор с примерами кода самого пайплайна.
Классная подача, чистая речь, умение доносить мысль! Спасибо вам!
Лайк и подписка
Как же Вы здорово объясняете! Можно Вас попросить сделать практичный подробный видос про Git / Github где Вы также простыми словами понятно объясняете всю суть и показываете реальные кейсы. Интересно увидеть как Вы
- загружаете Ваш проект на Гитхаб из Вашей IDE (возможно разными способами).
- как подключаете SSH
- как мерджите, пушите и тд
- как работаете в терминале (разные команды)
- rebase / cherry и тд
к сожалению, такое можно познать только на практике, ищите проект и единомышленников, создавайте репозиторий и практикуйтесь
ОЧЕНЬ сильно ждем практику
То чувство, когда больше 5 лет работаешь по процессу, а потом узнаешь, что он называется модным словом CI/CD.
А видос простой для понимания и познавательный.
Круто
Круто, круто. Примерил инфу на свой текущий проект. По полочкам удалось свои текущие знания разложить
Спасибо вам.Просто о сложном.Я -ручной тестировщик,пытаюсь набраться знаний,чтобы перейти в автоматизаторы на Python,чтобы найти новую работу,так как сейчас я только ручник. Уже немного умею писать автотесты для API и WEB.А вот CI/CD для меня темная лошадка.Теперь стало немного проще.Спасибо вам за уроки.
Здравствуйте! Большое спасибо за ваше полезное видео! У меня возник вопрос, который, думаю, будет интересен многим. Не могли бы вы рассказать о том, как правильно откатывать доработки (фичи), которые не прошли тестирование при использовании CI/CD? Какие существуют лучшие практики для минимизации рисков и ошибок в этом процессе? Очень хотелось бы увидеть ваше мнение и рекомендации по этой теме. Спасибо!
Спасибо! Более грамотного и доступного объяснения я не нашел! Желаю тебе развития и процветания. Вроде бы и простую вещь объяснил, а понятно для новичков объяснить только ты смог)
Реально очень крутая подача. Все по полочкам 👍
На реальном проекте dev никогда не мержится в main :)
В дев что только не валят, потом создается релезная ветка (еще наверняка с фичетоглами), тестировщики тестируют фичи своей команды, потом делают регресс тест и только после этого релейная ветка уходит в main и пользователи радуются новым фичам :)
На мой взгляд, самое очевидное и понятное объяснение сложного и многосоставного процесса
Артём, очень круто получилось! Продолжай так же 🎉
Очень хорошо объясняете, спасибо вам огромное. Простым языком объяснили человеку без профильного образования, работающего в этой сфере 2 месяца)
спасибо, наконец-то хоть кто-то понятно объяснил )
Наконец-то!!!! Хоть кто-то!!!! Доступно и понятно все обьяснил!!!! СПАСИБО!!!
спасибо)
Очень понятное объяснение даже для меня, психолога. Поскольку работаю в основном с айтишниками, приходится быть в теме.😊
Объясняешь им что такое ci/CD , да ?
AC\DC лучше
Не умничай, а сноси путина.
Прикольно, сочно рассказываешь. Чувствуется заинтересованность а не как обычно у всех - рассказ ради рассказа
Про необходимость знания ci/cd вы в точку. Сейчас в резюме есть требование хотя бы к пониманию процессов ci cd
Нам такой контент нравится)
Дулаю с 0 приложение без знаний программирования, эти знания мне очень помогут не сломать уже готовый прод, когда буду фиксить баги)) Спасибо)
Прикольная тема, щас на работе как раз этим на нескольких проектах занимаюсь, причём у нас используется bitbucket и когда я начинал, никто ничего не объяснял да и туториалов нормальных по битбакету нет, так что думаю всем полезно будет эту тему изучить. Спасибо за видос)
Артём, большое спасибо, объяснение - мощь 👍💪
Общее объяснение отличное, единственно я не могу прикинуть как бы я это понял если бы увидел это видео до того как начал работу в моей команде (команда очень сильная), так-то сейчас смотрю и кажется, что всё прям очень понятно и легко )
очень классная подача. разобрался с первого раза⚡️
Спасибо большое за понятное пояснение. Держи ❤
Очень доступно и интересно! Артём, спасибо👍
Ждём продолжения. Очень актуальная тема. Хотелось бы узнать как это чудо настроить.
Отличная подача. Продолжай, а мы ждем новых видео!
Спасибо! Очень информативно и не перегружает.
Мне даже как геймдев плюсовику полезно было, спасибо)
Искала медь, нашла золото! Спасибо!)
Все понятно и кратко. Лайк в поддержку канала.
Спасибо за видео. очень круто все рассказал, остался не совсем понятный этап. ты говорил про релизы, что там собираются несколько изменений, а как они запускаются, если сделав слияние ты уже развернул это на тестовом контуре. ну допустим 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 😎
Спасибо за труд
Лайк подписка. Еще бы как настроить видос был, было бы вообще круто🔥
В понедельник выйдет видео с настройкой)
Идеальный пример на практике. Осталось понять чем занимает devops инженер и на каком этапе
Запаковывает коробочки😂😂😂
Он как белый господин на поле, следит чтобы все работало/работали 😂
ХАРОШ
Продолжай развертывать 👍
Внатуре четко! Улыба от Братвы!
Спасибо. Очень доходчиво рассказано
Артем, жду с нетерпением пример реализации пайплайна от тебя, желательно с применением Jenkins and SonarQube
Только сегодня смотрел деплой, ждал CI/CD, а оно вон как :)
Continuous а не Continuos, но обяснение хорошее
Классный видос, спасибо!
Спасибо за объяснение!
В реальной практике конечно такое редко встречается, если говорить про релиз (cd), если говорить про обновление релизом продакшен контура (там где реальные пользователи). Обычно это не происходит автоматически по мерджу в основную ветку, а отдается протестированный билд (сборка) в виде докер образа с определенным номером команде девопсов - это те которые разворчаивают новый релиз на прод серверах. Причина этому в том что прод доступен малому числу людей со специальными правами. Если это банк то зачастую только команде девопсов от банка. Также разработка может вестись разработчиками с других компаний - аутсорсинг, и тогда также возможно что прод (основной сервер с приложением для реальных пользователей) может быть доступен только заказчику, а аутсорс команды передают им готовые релизные билды
По факту
Вообще супер видео
Реально, стало более понятно, спасибо :)
Oчень круто !
Привет, большой респект за видео. Скажи а есть ли у тебя видео по редакторам? Я сам использую Visual Studio Code но знаю есть много других крутых, такие как jetbrains и твой сегодняшний. хотелось бы решить для себя
Во мне кипит гнев и негодование. CI/CD это не про сборку и развертывания. Это про непрерывный процесс улучшения продукта. Т.е каждый день вносятся изменения в продукт и каждый день выкатываються изменения. Это про совокупность процессов. Про то как улучшать и экспериментировать каждый день
улучшение продукта - это коммит в репозиторий
CI/CD про сборку, тестирование и развертывание
@@artemshumeiko серьезно? Т.е если мы уберем CI/CD платформу то у нас ничего не получится? Мы не сможем собирать, тестировать и развертывать продукт?
@@abraham3345 когда ты приедешь устраиваться на работу и тебя спросят как ты будешь реализовать CI/CD процессы. Собес завершится через 5 секунд после того как ты начнешь рассказывать что то из этого видео
Я бы сказал так Простое сделаем сложным
Очень поверхностно - совсем для новичков, но общее представление дает. Забавно, что всего 2 стенда, но есть тесты :) Обычно стендов намного больше - dev, ift, psi, preprod, prod, ну и в нормальных компаниях, чтобы ветку main или master после мерджа залить в прод, не практикуют. Только через запросы на изменения с указанием версии. А так ну максимум она на preprod уедет, если настроено :)
осталось рассказать как именно настраивать пайплайн ))
Есть 2 книги. Первая называется Continuous Integration (CI) вторая называется Continuous Delivery (CD) этих двух книг достаточно чтобы разобраться что такое CI/CD и вы удивитесь прочитав их…
я удивлюсь, если кто-то в 2024 изучает devops по книжкам
Нет нужна ещё книга "/" как минимум
Вроде и да и вроде и нет. При таком объяснении ускользает суть пула потоков при асинхронном программировании. Он не просто один и не ждёт. Управление передаётся другим задачам пока идёт ожидание завершения уже запущенных. Под каждую новую задачу (обычно задача = новое подключение) выделяется новый поток и он выполняется до тех пор, пока не встретит I\O -bound задачу. Когда поток её встречает и начинает "ждать", этот поток как бы передаётся под новую задачу. Когда ответ буде получен эта задача будет готова выполняться дальше, как только под неё выделят какой-нибудь поток, освободившийся в других задачах.
Лучший, спс ❤
В моей компании нет dev, все происходило на прямую в main (т.к. проект начинался с 0 и соответственно нет надобности создавать отдельное окружение для тестирования). Как только проект завершат, тогда реализуют dev
Спасибо большое
Дарова мужик. Видео посмотрел. Можешь не удалять, вдруг еще кому то полезно или интересно будет посмотреть.
Такой вопрос неожиданный к тебе - ты девопс?
Шик!
Я девопс, тоже доводилось кхем,кхем, сталкиваться :D
супер, спасибо
Воооу контент подьехал
Делать CI/CD для одной буквы в HTML. Вот это уровень :)
А как можно автоматически затестить что стили не посыпались и не поехали?
а как же этапы до сборки ? статический анализ кода? юнит тесты ? это очень важные этапы CI
Нраица. Лукас выставлен.
🔥🔥🔥
Какую программу используете для демонстрации схемы? Ищем сейчас аналог миро)
Miro
Как происходит автоматическая и автоматизированная перестройка серверов на то, чтобы выдавать страницу с изменениями?
а сколько время простоя при деплое новых контейнеров? По идее еще надо настраивать реплики, чтобы старые контейнеры не умерли, пока новые полностью не запустятся
зависит от скорости загрузки контейнера
на моем проекте простой занимает 1-2 секунды
Если говорим про кубер, там простоя нет
@@artemshumeiko в сварме тоже нет, если настроить, у меня автодеплой бывает занимает минут по 20 на 4 этапа, а время простоя (когда приложение не отвечает пользователям) полсекунды ))
конечно в к8с это было бы проще настраивать, но я его ни разу не использовал, как-то вот не попадался он мне в проектах )
Привет. Не нашел ни в описании, ни в комментах сервис с помощью которого ты демонстрируешь схемы. Можешь сказать его название?
Miro
CI/CD - перевожу, постонно делать работу над проектом, вытягивая при этом деньги из заказчика (работа, ради работы)
Перед созданием ветки dev лучше бы сделать git pull)
Используют ли кубер на dev ветках, если в проде он есть?
да
сделай видос про кафку пж
Скоро будет по брокерам!!)
Тогда что в мастере? С точки зрения CD?
Баги. Так как на практике программисту срать, чё он написал, тестировщик не делает полную проверку (нет времени, а его автотесты - кусок говна), code review проведено на отъ***сь, т.к. Senior тусит где-нибудь в клубе, а баг всплывает в 3 часа ночи у Заказчика, который пишет тикет в техподдержку. Техподдержка неделю молчит, ничего не делая с тикетом, а потом руководство Заказчика идёт к менеджеру проекта с матами! В итоге МП сам ищет и отлавливает баг, его же детально описывает в задаче и сам всё тестирует🤣
В случае если мердж реквеств в дев апрувнули и код не прошел тесты, откатывается ли дев?
Я думаю, если работает достаточно большая команда разработчиков (больше 4-5 человек), то да.
Но чаще всего сборкан на dev ломается, если есть какой-то мелкий баг. Тогда он быстро фиксится и "домерживается" в dev
На больших, нормальных проектах не получится сделать мердж в основную ветку с ошибками в СІ. Там СІ работает так что когда открываеться мердже реквест, СІ имитирует мердж и проганяет все проверки на результате имитации мерджа (будто мердж реквест уже смерджован на основную ветку), и если СІ не проходит - мердж заблокирован.
@@someDude1368 как с миграциями работают в данном случае? Под каждый MR создается копия dev базы и на ней прогоняются миграции?
@@artemshumeiko У нас, из того что вижу в коде - каждый раз создается пустая база на которой применяется призма резет (чистит + применяет заново все миграции) и потом летят тесты, билды и т.д. Не уверен почему не используем копию БД, завтра спрошу у ребят.
Мне не понятно что там за тесты, по прошествии которых галочки ставятся? Это другие люди должны что-то сделать, или оно само что-то проверяет? И если оно само, то что это?
Эти тесты были написаны разработчиками, они прогоняются полностью каждый раз при новом коммите, чтобы убедиться, что все работает. Тесты прогоняются автоматически на CI сервере (про сервер рассказывал в видео)
это мировые программисты должны проверить и галочку поставить
10/10
вау, теперь я знаю кто делал фронт для солвит))
Нифига себе, нам контора меняла одну букву две недели и взяли 200к.
Лови лайк!
❤❤❤
На больших, нормальных проектах не получится сделать мердж в основную ветку с ошибками в СІ. Там СІ работает так что когда открываеться мердже реквест, СІ имитирует мердж и проганяет все проверки на результате имитации мерджа (будто мердж реквест уже смерджован на основную ветку), и если СІ не проходит - мердж заблокирован.
Работодатели афигели, CI/CD это поле девопса, а не разработчика. Чего они мой хлеб забирают? ((((
Разработчикам только базу нужно знать. Все равно весь хардкор на плечах девопсов)
CICD это скрипт (#!/bin/sh) запускаемый по событию в репе. Остальное - лирика и синтаксический сахар.
лайк подписка