Post on 28-Nov-2014
description
transcript
Управление Изменениями и Управление Релизами: преодоление барьера
Декабрь 2012
Алексей Ионин
• Проблема
• Разработка против Операций (Dev vs. Ops): Процессные расхождения
• Правильный подход
• Практики непрерывной поставки (Continuous Delivery)
• Поставка с фазами приемки (QA, UAT…)
Содержание
3
Проблема:
Самая важная проблема, которую мы выделяем как профессионалы в разработке ПО, следующая: если у кого-то появилась хорошая идея, как доставить её решение пользователям максимально быстро?Jez Humble; David FarleyContinuous Delivery: Reliable Software Releases through Build, Test, and Deployment AutomationPublisher: Addison-Wesley Professional
4
Dev-Ops дилемма
Ожидания бизнеса от ИТ постоянно растут
Разработка ведется все интенсивнее
Поддержка концентрируется на эффективности и стабильности
Когда эти два мира сталкиваются, начинается
настоящее «веселье»!
InnovationDemand
Agile Development
ReliableServices
Complete Chaos
Бизнес IT Операции Ops
IT Разработка Dev
• Проблема
• Разработка против Операций (Dev vs. Ops): Процессные расхождения
• Правильный подход
• Практики непрерывной поставки (Continuous Delivery)
• Поставка с фазами приемки (QA, UAT…)
Содержание
6
Apps
Разработчики творят в своих средах и на своих инструментах
Бизнес CIOРелизПотребност
ь
РазработкаIT Разработка
Dev
7
Разработчики имеют свои процессы и регламенты
Apps
РелизПотребность
Разработка
V-Model Waterfall Agile ScrumFa
ll
CMMI
CMII
SPICE
26262
DoD
8
В отделе обслуживания свои ITSM системы
Бизнес CIO
Операции
Запрос Исполнение
Услуга
IT ОперацииOps
9
Отдел операций следует своим процессам
SLA’s ITIL ITSM
Операции
Запрос
Услуга
Theory of Constraint
ITIL
Six Sigma
Process and
Operations Manageme
nt
CMM
Исполнение
10
А в результате..?
11
Overly complex processes?
“Слишком много процессов – это
примерно также плохо как и их недостаток.”
Robert Aiello; Leslie Sachs
Configuration Management Best Practices: Practical Methods that Work in the Real World
Publisher: Addison-Wesley Professional
Вывод 1: существенное число инцидентов как результат неудачного внедрения
изменений!
12
Вывод 2: слабый уровень взаимодействия между группами разработки и
сопровождения
13
Операции – тормозят всю разработку75% всех опрошенных определили, что именно в отделе обслуживания происходят все задержки с доставкой приложений бизнесу и не поддерживают Agile инициативы
Разработчики – не помогают в поддержке72% всех опрошенных определили, либо сотрудники сопровождения никак не могут взаимодействовать с разработчиками, либо разработчики только частично помогают в решении задач обслуживания Что в итоге?
91% всех опрошенных считают, что их бизнес спонсоры не считают ИТ полноценным партнером
14
Вывод 3: низкий уровень автоматизации процессов ITSM приводит к…
15
Процент респондентов, оценивших процессы ITSM как ручные или неопределенные
множественным нестыковкам процессов
Процент респондентов, оценивших интеграцию процессов как ручную или неопределенную
Вывод 4: Изменения и Релизы изолированы друг от друга
16
92% респондентов сообщают о наличие проблемы с управлением изменениями и релизами
29% не имеют информации о всех происходящих активностях25% не могут адресовать изменения достаточно оперативно
25% не могут определить статус доставки изменений
Вывод 5: Низкий уровень применения анализа влияния изменений
17
Анализируют влияние изменений в приложениях
Ограниченно либо совсем не используют информацию из CMDB/CMS
Анализируют влияние изменений в инфраструктуре
• Проблема
• Разработка против Операций (Dev vs. Ops): Процессные расхождения
• Правильный подход
• Практики непрерывной поставки (Continuous Delivery)
• Поставка с фазами приемки (QA, UAT…)
Содержание
19
Есть ли выход..?
20
Пока мы не выбросили все это…
“Недостаток процессов значит, что вы, вероятно, будете
постоянно делать одни и те же ошибки. Но вам также несомненно необходимо уверенно достигать
поставленных целей на повторяющейся основе.”
Robert Aiello; Leslie Sachs
Configuration Management Best Practices: Practical Methods that Work in the Real World
Publisher: Addison-Wesley Professional
21
Принцип 1: Договоритесь об Общем регламенте взаимодействия процессов
Потребность
Релиз
Приложения
Операции
Запрос Исполнение
Услуга
Разработка
DEV РЕЛИЗ OPS
CMMI
CMII
SPICE
26262
DoD
Theory of
Constraint
ITIL
Six Sigma
POM
CMM
22
Принцип 2: Процессы должны быть сквозные, интегрированные и единые для всех
TEST
OPS
DEV
Стандартизировать процесс разработки
Стандартизировать процесс тестирования
Стандартизировать процесс доставки
Принцип 3. Важность и ценность централизованного и версионного хранилища релизов (хотя бы)
23
РазработкаОперации
Услуга
Разработка
• Только проверенный код
• Только готовые сборки
• Четкий процесс сдачи
Релиз
• Подготовка структуры сборки для удобного развертывания
• Безопасный, закрытый и проверенный репозиторий
Операции
• Установка только из проверенного источника
• Интеграция с CMDB
24
Infrastructure as Code.
“You need to make it reproducible and programmatic. Hence virtual machines to shield software from configuration issues. Hence Puppet and Chef to automate configuration, so you know every machine has an identical software configuration and is running the right services. Hence Vagrant to ensure that all your virtual machines are constructed identically from the start.”
O'Reilly Radar (http://s.tt/1kHIs)
25
To Gold Image or not to Gold Image…
When you produce a “gold disk” and manufacture thousands (or millions) of copies, the penalties for getting something wrong are huge. If there’s a bug, you can’t fix it until the next release. In this environment, a software release is a huge event.
O'Reilly Radar (http://s.tt/1kHIs)
• Проблема
• Разработка против Операций (Dev vs. Ops): Процессные расхождения
• Правильный подход
• Практики непрерывной поставки (Continuous Delivery)
• Поставка с фазами приемки (QA, UAT…)
Содержание
27
Что на счет непрерывной поставки
PROD
UAT
UAT
UAT
DEV
DEV
DEV
DEV
DEV
28
Подход непрерывной поставки (Continuous Delivery) – в теории
DEV CI CI TEST UAT PROD
Automate• Validate
Deploy• Validate
• Проблема
• Разработка против Операций (Dev vs. Ops): Процессные расхождения
• Правильный подход
• Практики непрерывной поставки (Continuous Delivery)
• Поставка с фазами приемки (QA, UAT…)
Содержание
30
А на практике, непрерывная поставка… прерывается фазами приемки
DEV CI CI TEST GATE UAT GATE PROD
Непрерывная поставка на первых шагах
Фазы контроля приемки Операциями
Поддержка подхода DevOps
Интеграция процессов
31
Мифический метод?
@DEVOPS_BORAT: For understand devops terminology you need of replace 'continuous' with 'half ass automated'.
32
Принцип 4. Ценности DevOps во многом обеспечиваются реализацией принципов непрерывной поставки
Снижение рисков за счет реализации более частых и меньших изменений
Разработчики лучше понимают инфраструктуру, где работают их приложения
Поддержка получает представление о процессе разработки изменений
Простые интегрированные процессы образуют полный замкнутый цикл внедрения изменений
Процессы можно автоматизировать и свести влияние человеческого фактора на сбои в процессах к минимуму
Улучшение взаимодействия между группами Dev and Ops
Операции
QAРазработк
а
DevOps
33
Принцип 5. Постройте процесс. Пробуйте. Измеряйте. Оптимизируйте. Пробуйте. Измеряйте…
2. Просто для пользователейДля быстрой адаптации
5. Готовые отчеты и метрикиДля возможности постоянного совершенствования процессов
3. Наглядность и прозрачность
Для быстрого решения проблем
4. Готовое решение ITIL Для использования лучших практик
1. Гибкость процессного подхода
Для снижения TCO
34
Ответы на ваши вопросы
35
Спасибо
Major Financial Services FirmRealizing The Dev+Ops Vision
36
ITSM / OperationsService
Fulfillment6 Service desk tools to
replace
12+ Lotus Notes DBs
40+ Dev + Ops processes
2000 Global employees
Release
Serena Service Manager
Deployment Management
Production Incident Management
Vendor Management
Business Operations
Application Lifecycle
Management
37
Serena Software: Bridging Dev + Ops
Serena Service Manager +
Serena Release Manager
Integrates Dev + Ops
Process-based approach