Pull to refresh

Comments 9

Спасибо! Довольно интересно. На первый взгляд вроде все понятно.
Однако есть пара вопросов сходу:
— конкретно вы используете сейчас эту связку только для Win окружений? Там все понятно, powershell, powershell и снова powershell.
Да, я видел, что уже есть поддержка nix, но как это сейчас работает? И работает-ли у вас на конкретных проектах?
А связку nix + Jenkins + Nexus + Ansible, а еще поверх Octopus уже пробовали? Как я понял Octopus удобен в плане оркестрации ЖЦ, но собственного CI у него нет? Можно-ли тот же Jenkins им заменить?
Учитывя, что у Jenkins того же есть огромное множество плагинов для CI и AD.
Заранее извиняюсь за структуру вопросов :-)
Мы у себя используем и для линуксовых инстансов — там скрипты по умолчанию можно писать на PowerShell / C# / bash / F# для выполнения в процессе деплоя на инстансе, так что почему нет. Конкретно у нас заливается статический контент на веб-ноды под линуксом и потом некоторые действия скриптами выполняются. Так что можно и на вин и на никс окружениях использовать.
Остального у нас нет — ТимСити + Октопус пока хватает, но уже прорабатываем планы развития.
Да, в нашей команде мы пока деплоим только в Windows окружения, но вот наши соседи деплоят .Net Core приложения в Linux, и так как они изначально строили свою систему на основе микросервисов, то сейчас они деплоят через октопус более 30 сервисов. В общем виде это выглядит как пуш пакета на сервер + bash-скрипт для его распаковки и перенастройки сервиса.
Насчет CI — да, Octopus его не имеет, это система для деплоев, не для сборки и запуска юнит/интеграционных тестов и заменить им всё не получится. У нас вместо Jenkins TeamCity, соотвественно CI часть проходит на нём, а вопросами деплоя занимается Octopus.
Отличная статья, большое спасибо! Такой вопрос: а как у вас устроен репозиторий, а точнее ветки в них (release-branch, dev, master и т.д.), как происходит release management и тестирование? Заранее большое спасибо!
Приветствую.
Мы используем подход feature-branch, когда на каждую задачу создается по ветке. Ветки отбиваются от релизных веток (в статье был пример V10.1 и V11.0). После разработки задачи и ревью она попадает к тестировщику, которые решает, можно ли её сразу мерджить в релизную ветку или сперва следует провести изолированное тестирование (если задача потенциально опасная). В конечном итоге ветка мерджится в версионную, на которой гоняются автотесты и проводится ручное тестирование. В некоторый момент времени релизная ветка «замораживается», на ней проводится нагрузочное и регрессионное тестирование, после чего её можно деплоить.

Спасибо за ответ! Только не совсем понял, что у вас является основной веткой, вроде master'а? От чего вы ответвляете релизные ветки и куда их потом сливаете? И как хотфиксы попадают во все релизные ветки, если их несколько?

Новая релизная ветка (самая старшая) отбивается от мастера. Ветки для минорных релизов и хотфиксов отбиваются от ближайшей мажорной (например V21.0.1 будет отбита от V21.0). Соответственно при мердже пулл-реквеста задачи в соответствующую этой задаче релизную ветку код будет прокинут во все старшие ветки и закончится мастером. Эта политика мерджей пулл-реквестов настроена в Bitbucket.
Например делаем задачу для V21.0.1, но уже начали разработку V21.1 и V22.0. В этом случае при мердже фича-бранча в V21.0.1 Bitbucket автоматически смерджит его дальше в V21.1, V22.0 и master.
То есть, это функция bitbucket, дублировать PR из младших версий в старшие? Подскажите название пожалуйста :)
Да, это фича Bitbucket, называется Automatic branch merging. Подробная информация с примерами настройки есть в документации.
Sign up to leave a comment.