#управление_релизами — Public Fediverse posts

5 симптомов скорой смерти таск-трекера в команде разработки

Привет, Хабр! Меня зовут Артем Герасимов, я владелец продукта. В ИТ-индустрии из года в год можно наблюдать одну и ту же картину: разработка выглядит управляемой, задачи двигаются по доске и закрываются. Но стоит спросить что вошло в последний релиз, где исправили конкретный баг и сколько времени команда тратит на новую функциональность, а сколько – на исправления, и оказывается, что целостной картины нет. И чаще всего проблема не в дисциплине команды, а в том, что таск-трекер перестал отражать реальный цикл разработки.

https://habr.com/ru/companies/simpleone/articles/1008914/

#Тасктрекер #SDLCсистема #управление_разработкой #Поддержка_и_разработка #управление_релизами #инструменты_для_команды

[Перевод] Автоматизация CI/CD: «замораживаем развёртывания» в GitLab

У большинства команд CI/CD уже есть пайплайны, мониторинг и «безостановочные» релизы, но как только приближается крупное событие, чёрная пятница или просто длинные праздники, внезапно выясняется, что надёжного способа одновременно «заморозить» деплой десятков сервисов нет. GitLab умеет freeze-периоды на уровне проекта, но в мире микросервисов и сотен репозиториев это быстро превращается в ручной квест и источник случайных выкатов в прод. В статье разбираем, как с помощью отдельного проекта, GitLab CI и небольшого Python-скрипта автоматизировать групповую заморозку развёртываний: централизованно задавать расписание, распространять его на все нужные проекты и при этом не ломать привычный workflow команды. К подробностям

https://habr.com/ru/companies/otus/articles/972162/

#gitlab #cicd #GitLab_CICD #управление_инфраструктурой #заморозка_деплоя #пайплайны #автоматизация #стабильность_среды #управление_релизами #микросервисы

[Перевод] Автоматизация CI/CD: «замораживаем развёртывания» в GitLab

У большинства команд CI/CD уже есть пайплайны, мониторинг и «безостановочные» релизы, но как только приближается крупное событие, чёрная пятница или просто длинные праздники, внезапно выясняется, что надёжного способа одновременно «заморозить» деплой десятков сервисов нет. GitLab умеет freeze-периоды на уровне проекта, но в мире микросервисов и сотен репозиториев это быстро превращается в ручной квест и источник случайных выкатов в прод. В статье разбираем, как с помощью отдельного проекта, GitLab CI и небольшого Python-скрипта автоматизировать групповую заморозку развёртываний: централизованно задавать расписание, распространять его на все нужные проекты и при этом не ломать привычный workflow команды. К подробностям

https://habr.com/ru/companies/otus/articles/972162/

#gitlab #cicd #GitLab_CICD #управление_инфраструктурой #заморозка_деплоя #пайплайны #автоматизация #стабильность_среды #управление_релизами #микросервисы

[Перевод] Автоматизация CI/CD: «замораживаем развёртывания» в GitLab

У большинства команд CI/CD уже есть пайплайны, мониторинг и «безостановочные» релизы, но как только приближается крупное событие, чёрная пятница или просто длинные праздники, внезапно выясняется, что надёжного способа одновременно «заморозить» деплой десятков сервисов нет. GitLab умеет freeze-периоды на уровне проекта, но в мире микросервисов и сотен репозиториев это быстро превращается в ручной квест и источник случайных выкатов в прод. В статье разбираем, как с помощью отдельного проекта, GitLab CI и небольшого Python-скрипта автоматизировать групповую заморозку развёртываний: централизованно задавать расписание, распространять его на все нужные проекты и при этом не ломать привычный workflow команды. К подробностям

https://habr.com/ru/companies/otus/articles/972162/

#gitlab #cicd #GitLab_CICD #управление_инфраструктурой #заморозка_деплоя #пайплайны #автоматизация #стабильность_среды #управление_релизами #микросервисы

[Перевод] Автоматизация CI/CD: «замораживаем развёртывания» в GitLab

У большинства команд CI/CD уже есть пайплайны, мониторинг и «безостановочные» релизы, но как только приближается крупное событие, чёрная пятница или просто длинные праздники, внезапно выясняется, что надёжного способа одновременно «заморозить» деплой десятков сервисов нет. GitLab умеет freeze-периоды на уровне проекта, но в мире микросервисов и сотен репозиториев это быстро превращается в ручной квест и источник случайных выкатов в прод. В статье разбираем, как с помощью отдельного проекта, GitLab CI и небольшого Python-скрипта автоматизировать групповую заморозку развёртываний: централизованно задавать расписание, распространять его на все нужные проекты и при этом не ломать привычный workflow команды. К подробностям

https://habr.com/ru/companies/otus/articles/972162/

#gitlab #cicd #GitLab_CICD #управление_инфраструктурой #заморозка_деплоя #пайплайны #автоматизация #стабильность_среды #управление_релизами #микросервисы

Как мы автоматизировали и упростили процесс ведения релизов

До начала 2020 года наша команда принимала участие в релизах в качестве группы тестировщиков во главе с координатором. Процесс был полностью ручным, длительным и требовал достаточно много времени. Координатор занимался формированием команд на регрессы, отслеживанием активностей, ведением дашборда и прочими организационными мероприятиями внутри команды тестирования. При этом основной функционал — формирование состава релиза, коммуникация между командой тестирования и разработчиками, ведение встреч и прочих мероприятий по релизам — был на смежном управлении: всё это делали релиз-менеджеры, и именно они были головой релиза. После трансформации весь описанный выше функционал перешёл в одну группу — «Управление релизами». Коммуникации, работу с командой тестирования, отчётность и встречи — всё стала вести наша команда. Большая часть коммуникаций проходила в почте. Сбор, фиксацию состава релиза и отчётность — всё приходилось делать вручную. Процесс подготовки к релизу занимал до пяти рабочих дней. Релиз-менеджер каждый день из confluence сохранял pdf-файл со списком задач и сравнивал состав релиза на предмет добавленных и исключённых задач. После включения задачи в релиз тест-менеджеры самостоятельно вносили её на страницу «Актуализация регрессов» на confluence согласно цветовой легенде и определяли, какие задачи требуют изменения в тестовой модели, а какие ещё не брали в работу. Было много ручных активностей релиз-менеджеров и тест-менеджеров, и это заставило нас подумать над частичной автоматизацией процесса ведения релизов. Дальше я расскажу в деталях, как всё было «до» и как стало «после».

https://habr.com/ru/companies/homebank/articles/799369/

#автоматизация #ведение_релизов #управление_релизами #нагрузочное_тестирование #интеграционного_тестирования