мы это решаем с помощью геррита

@dvoikik пересобирать. qa должны тестировать не имидж, а код. и от пересборки не должно ничего меняться. в любом другом случае возникает проблема разрыва кода и энва

Что именно? И как gerrit может быть интегрирован в CI/CD pipeline?

Всем привет! У меня вопрос такой, никак не могу найти что-то, что меня бы направило в правильное русло. Есть git репозиторий, с которым будут работать по Git Flow. В нем есть ветки develop, master и будут создаваться release/$version ветки для каждого релиза и hotfix/$version для исправления багов, найденных в master ветке. Я пытаюсь найтроить VSTS для CI/CD (Не важно, в чем именно, вопрос не по имплементации). В данный момент я вижу flow следующим образом: Когда происходит push в develop, создается docker image ($image):($version)-dev($revision) и деплоится в kubernetes в dev namespace Когда происходит push в release, создается docker image ($image):($version)-rc($revision) и деплоится в kubernetes в qa namespace Когда происходит push в master, создается docker image ($image):($version) и деплоится в kubernetes в prod namespace Вопрос: Стоит ли делать так? Я читал, что image из qa должен в случае успешных тестов быть развернут в продакшн, а не собран снова. Как в этом случае быть? Я вижу 2 варианта: 1) Собирать image для qa из master ветки. Но в этом случае непонятно, что делать, если QA не принимает билд и нужно еще внести некоторые правки, потому что если код попал в мастер, он уже должен быть без известных изъянов. 2) Собирать image для qa из release ветки и этот же image отправлять в prod, если QA принимает билд. Но в этом случае нарушается правило "В master ветке всегда имеем код, который сейчас в продакшне". Я понимаю, что все это очень субъективно и может быть много разных вариантов решения. Я буду рад любым предложениям и конструктивной критике. Спасибо за уделенное время.

решаем проблему тестирования изменений до их фактического мерджа. >И как gerrit может быть интегрирован в CI/CD не понял вопроса.

в этой схеме, образы создаются для dev/qa/master по-разному? или только называются с префиксом?

Только называются

Ну ведь моя конечная цель состоит в том, чтобы все изменения в кодовой базе автоматически попадали в соответсвующие окружения, т.е. от разработчиков требуется только работать согласно gitflow и больши ни о чем не думать.

Всем привет! У меня вопрос такой, никак не могу найти что-то, что меня бы направило в правильное русло. Есть git репозиторий, с которым будут работать по Git Flow. В нем есть ветки develop, master и будут создаваться release/$version ветки для каждого релиза и hotfix/$version для исправления багов, найденных в master ветке. Я пытаюсь найтроить VSTS для CI/CD (Не важно, в чем именно, вопрос не по имплементации). В данный момент я вижу flow следующим образом: Когда происходит push в develop, создается docker image ($image):($version)-dev($revision) и деплоится в kubernetes в dev namespace Когда происходит push в release, создается docker image ($image):($version)-rc($revision) и деплоится в kubernetes в qa namespace Когда происходит push в master, создается docker image ($image):($version) и деплоится в kubernetes в prod namespace Вопрос: Стоит ли делать так? Я читал, что image из qa должен в случае успешных тестов быть развернут в продакшн, а не собран снова. Как в этом случае быть? Я вижу 2 варианта: 1) Собирать image для qa из master ветки. Но в этом случае непонятно, что делать, если QA не принимает билд и нужно еще внести некоторые правки, потому что если код попал в мастер, он уже должен быть без известных изъянов. 2) Собирать image для qa из release ветки и этот же image отправлять в prod, если QA принимает билд. Но в этом случае нарушается правило "В master ветке всегда имеем код, который сейчас в продакшне". Я понимаю, что все это очень субъективно и может быть много разных вариантов решения. Я буду рад любым предложениям и конструктивной критике. Спасибо за уделенное время.

а, понял. идея это натянуть на git-flow... мы от этого отказались. :)

каких-то стандартных решений адаптации гит-флоу к реальности я не встречал. каждый случай индивидуален

ну, менять всё равно что-то придётся, раз ты пришёл к пониманию проблемы

https://www.youtube.com/watch?v=G3nELxmECd8

О, я вроде его смотрел. Сейчас пересмотр еще раз, на всякий, спасибо.

>работа с VC - люди, вероятность ошибок больше вот именно. потому у нас запрещен прямой пуш. всё через реквесты и автоматику. основное требование - ветка должна быть протестированной в любой момент времени. т.к. она же используется и для тестов. сломанная ветка - остановка процесса разработки

разработка ведётся в мастере. релиз отпочковывается в ветку stable/*. хотфиксы черрипикаются в неё из мастера

ну, не все. согласно SLA

особенно, если заказчик просит новую фичу протащить под видом хотфикса

не уверен что я именно его имею ввиду, бегло вроде оно

Да, это он. Поставил метку на этот момент. Здесь я как раз вот это и услышал, потому у меня эти вопросы и возникли. https://youtu.be/G3nELxmECd8?t=26m14s

Все привет я только начал знакомится с CI подскажите как настроить его на jenkin or aws .

в чем вопрос собсно? берешь тачку ставишь там жаву и погнал по мануалу

Вопрос думаю в - jenkins or aws

Посоны, помогите плз, я чот туплю. Есть кароч ансибловский плейбук который выкатывает контейнеры. Чот не догоняю, как его заставить выполниться в пайплайне дженкинса. Ансибл в отдельной репе от проекта

Посоны, помогите плз, я чот туплю. Есть кароч ансибловский плейбук который выкатывает контейнеры. Чот не догоняю, как его заставить выполниться в пайплайне дженкинса. Ансибл в отдельной репе от проекта

А трансляция не предусмотрена?

https://tproger.ru/curriculum/devops/

за 150 раз большее кол-во работы

за 150 раз большее кол-во работы

И здесь стонешь ?

девопсовство хуита, а вот java программирование не хуита.

девопсовство хуита, а вот java программирование не хуита.

ты вообще искал себе раба недавно за 60к

ну судя по вакансиям - так и выходит

не там ищете