IT + Управление проектами

Также найти  множество интересной и полезной информации вы можете на канале Самоучки IT (Управление проектами) https://t.me/+NfVrLMxdKS0yNDNi

CI/CD - это Continuous Integration, Continuous Delivery - непрерывная интеграция, непрерывная поставка. Это одна из DevOps-практик, которая также относится к Agile-подходу. Автоматизация развёртывания позволяет разработчикам сфокусироваться на реализации бизнес-требований, качестве кода и безопасности.

В чем фишка? Это автоматизированный конвейер, который цепляет только что написанный код к главной кодовой базе, гоняет всякие тесты и автоматом деплоит обновлённую версию.

Многие ошибочно думают, что CI и CD - разные процессы. Но на самом деле они связаны как матрёшки. Внутри - непрерывная интеграция, снаружи - непрерывная доставка. Основная их цель - увеличить стабильность выпусков и ускорить весь этот процесс.

Давайте по-полочкам разберём этапы CI/CD цикла:

• Код . На этом этапе идёт написание кода, покрытие его тестами, commit и push в систему контроля версий

• Сборка. Система вроде Jenkins автоматически собирает ваши изменения и запускает их тестирование.

• Тестирование. После успешного прохождения автоматических тестов изменения отдаются на ручное тестирование.

• Релиз. После того, как команда тестировщиков проверила все изменения, у нас получается стабильная версия продукта – релиз-кандидат.

• Деплой. Релизную ветку мы загружаем и разворачиваем на продакшен-сервере клиента.

• Мониторинг. Следим за развёрнутой версией продукта и в случае проблем стабилизируем её или фиксим.

• Планирование. Планирование новой функциональности или внесение изменений для будущих релизов.

Теперь разберем, как CI/CD помогает автоматизировать эти шаги.

Непрерывная интеграция — это автосборка и тестирование всего кода в общем репозитории после слияний. Команды часто используют feature flags или ветки для контроля готовности функционала. CI позволяет выявлять проблемы до деплоя кривого кода на прод.

На этапе сборки упаковываются все компоненты ПО и БД. Запускаются модульные, функциональные, регрессионные тесты и другие виды тестов для проверки стабильности. Это непрерывное тестирование - важная часть CI/CD.

Следующий этап - непрерывная поставка. Тут автоматизируется процесс подготовки релиза к деплою после CI. Настраиваются параметры окружений, выполняются необходимые запросы для перезапуска сервисов и т.д. DevOps команда берет протестированный релиз и выполняет все действия для деплоя на проде в пару кликов.

Финальный шаг - непрерывное развертывание (CD). Он включает все предыдущие шаги и суть его в том, чтобы развернуть изменения программиста в продакшене без дополнительных действий. Но для этого в команде должна быть культура мониторинга, чтобы в случае проблем можно было оперативно откатить изменения.

Ещё один важный момент - CI/CD конвейеры широко используются с Kubernetes и бессерверными архитектурами. Контейнеры позволяют стандартизировать упаковку, упрощают масштабирование окружений. А бессерверные вычисления типа AWS Lambda интегрируются в конвейеры через плагины.

В компаниях, где CI/CD внедрён, часто улучшаются ключевые DevOps метрики: частота деплоев, lead time для изменений, время восстановления после инцидентов. Но для этого нужно наладить весь процесс по методологии DevOps.

В общем, CI/CD - мощная практика для автоматизации разработки и деплоев. Команда разработчиков просто пишет код, а остальные шаги в конвейере выполняются на автомате. Такой подход экономит время и обеспечивает стабильность ПО.

А чтобы все это не было просто сухой теорией, расскажу реальный кейс из жизни.

Однажды мне довелось поработать в одной прогрессивной конторе, где CI/CD был поставлен на самом деле очень грамотно.

Команда разработчиков активно писала код в feature branches регулярно создавая pull request, для слияния изменений в мастер-ветку. После каждого такого merge автоматически запускался конвейер CI. Система типа Jenkins забирала новый код, собирала приложение, гоняла batch -тестов - юнит, интеграционные, регрессионные. Все это не занимало больше 10 минут.

Если все тесты проходили успешно, включался следующий этап - непрерывная поставка. Сборка артефактов, подготовка всех зависимых сервисов, настройка тестовых окружений — все это выполнялось автоматически конвейером. Разве что DevOpsы мониторили процесс на предмет ошибок.

Но самое крутое начиналось дальше. После успешной поставки в тест-окружения запускалась финальная стадия - непрерывное развёртывание. Конвейер автоматически деплоил собранную версию на продакшен сервера, обновлял контейнеры, переключал трафик, и свежая фича становилась доступной всем пользователям!

Согласитесь, это было очень круто - от написания строчки кода до релиза проходило всего минут 30 максимум, если все шло штатно. При этом человеческое вмешательство требовалось только на самом старте - commit изменений. Остальным занималась магия CI/CD.

Плюс в углу офисной площадки красовался большой ТВ-экран, где транслировался статус всех активных сборок и деплоев - кто закоммитил (committed), на какой стадии идёт процесс, есть ли ошибки. Так что любой мог присмотреться если что пошло не так.

В общем, навороченный CI/CD конвейер сильно упрощал жизнь разработчикам и DevOpsам, позволяя много времени сэкономить на рутинных задачах поставки кода на прод. Да и со стабильностью системы не было никаких проблем благодаря повсеместному тестированию. Так что если доведёте CI/CD до ума, то только в плюсе будете!

Ну что? Я надеюсь, теперь у вас более-менее все встало на свои места с этой концепцией. Оставляйте свои мнения и кейсы в комментах.  Будем продолжать разбираться в крутых IT-темах на канале Самоучки IT(Управление проектами)https://t.me/+NfVrLMxdKS0yNDNi

🃏Что такое покер планирования?

Покер планирования - это инновационный метод, который используется в Agile-среде для проведения совместной оценки задач. В основе этого подхода лежит коллективное решение команды по сложности и временным затратам на выполнение конкретной задачи. Участники команды обычно прибегают к специальным картам с числовыми значениями (обычно в пределах от 0 до 100), чтобы выставить оценку каждой задаче.
Одним из основных принципов метода является стремление к единогласному решению, чтобы обеспечить общее понимание сложности задачи и достичь консенсуса среди всех участников. Покер планирования способствует улучшению коммуникации в команде, более точного понимания требований и повышению прозрачности процесса разработки программного продукта.

"Две трудные задачи стоят перед человеком: во-первых, знать, когда начать, во-вторых — когда закончить". — Пауло Коэльо

🔓Как выглядит процесс покер планирования? | Story Points

Важно отметить, что оценка в покер планировании происходит не в часах, а в Story Points. В будущем мы отдельно расскажем о важности этого термина, однако сейчас важно быстро ввести читателя в курс дела.

Алекс (Менеджер): Какова вероятность того, что задача будет закрыта за неделю?
Фёдор (Разработчик): Мне кажется справлюсь)
Алекс: Можешь назвать конкретное число
Фёдор: 70-85%
Алекс: Значит может понадобиться 8-10 дней?
Фёдор: О, я не знаю… Я на девяносто три процента, что работа будет сделана менее чем за 9 дней.

Я думаю такой диалог знаком любому работнику в сфере IT. К сожалению проблемы в оценке на этом не заканчиваются, но некоторые из них решают Story Points. Суть состоит в том, чтобы не давать оценку задаче в конкретных часах, а использовать абстрактные единицы, для общего понимания градации задач между собой и оценке трудозатрат.
Приведём стандартные примеры Story Points:

-Шкала Фибоначчи : 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89… , дать оценку задачи не в часах а поставить один из цифр в шкале.
-Размеры Футболок : L, M, XL, XXL .. , дать оценку задачи в размере футболки, заранее договорившись о значении каждого размера. L - задача не требующая особых усилий (изменить цвет кнопки), XXL - фундаментальная задача на десятки часов.

Теперь мы поняли из чего состоит оценка задач в Покер Планировании. Однако как же выглядит сам процесс?

⏳Шаг 1. Раздача карт - на данном этапе выбирается в чём конкретно будет оцениваться задача (Story Points), всем участником раздаются карты. Пусть это будут числа Фибоначчи от 1 до 89. Также иногда могут добавляться специальные карты : очень простая задача, просьба перерыва и так далее...

🔭Шаг 2. Ознакомление с задачами - на данном этапе выбирается в чём конкретно будет оцениваться задача (Story Points), всем участником раздаются карты. Пусть это будут числа Фибоначчи от 1 до 89.

🎓Шаг 3. Обсуждение — по озвученным задачам высказывается каждый участник сессии:

⚫Как будет происходить выполнение выполнение

⚫Сколько человек должно принять участие в спринте

⚫Какие технологии нужны для работы

⚫Что может замедлить процесс разработки

📊Шаг 4. Оценка — по озвученным задачам высказывается каждый участник сессии:
Все игроки выкладывают карты лицевой стороной вниз. Особенно важно соблюдать это правило, чтобы не повлиять на оценки других участников.
После проведения голосования карты должны быть перевернуты лицевой стороной вверх. Команда сможет увидеть результаты оценок и продолжить обсуждение вопросов.
Таким образом, следует держать карты в тайне до окончания голосования, а затем открыть результаты для всех участников.

✅Если оценка выглядит следующим образом: 2 / 3 / 1 / 13, стоит задуматься и обсудить почему последний коллега дал такую оценку, возможно он обладает какой-то дополнительной информацией.

🎯Шаг 5. Достижение понимания — если члены команды показали близкие по значению карты – консенсус достигнут. Цифры на картах сильно различаются — участники должны объяснить свой выбор Если кто-то поменял свою оценку, нужно обсудить данный выбор.

"Жизнь — это тот же покер. Сплошной риск, которого никак не избежать". — Эдвард Нортон

⚙Почему покер планирования это важно | Резюмируем.

Planning poker появился из-за сложности оценки комплексных задач, которые могут включать в себя дизайн / разработку и отладку бизнес процессов.

-В методологии Scrum на часть планирования отводится достаточно мало времени (обычно это нужно успеть сделать за 1 час), поэтому такой метод прекрасно помогает посмотреть на задачу с разных сторон, а также закончить этот процесс быстро.
-Оценка проводится в story points, условных единицах, которые помогают быстро ранжировать задачи.
-Важно на первом этапе проводить оценку "закрыто", чтобы не повлиять на мнение других участников.

📖В нашем Telegram канале мы выложили 5 ЛУЧШИХ книг для Project Manager'ов + ссылки на их чтение!

https://t.me/itguru_pm - ПРИСОЕДИНЯЙСЯ!