Петр Клименко. DevOps Трансформация для SIEBEL CRM
Download as PPTX, PDF0 likes481 views
DevOps Трансформация для SIEBEL CRM
![Ограничения платформы [Siebel CRM]
Ограничения унаследованной платформы разработки:
Нет версионного контроля
Как следствие, нет code review
Как следствие, нет инкрементальных поставок
Нет Framework для модульных и unit-тестов](https://image.slidesharecdn.com/devopslegacy-legacyisnotexcuseanymore1-170603164347/85/DevOps-SIEBEL-CRM-5-320.jpg)
![Начало борьбы:
Unit-тесты
Расковыряли API системы
Запилили Framework для unit-тестов [Java, jUnit]
Обучили не-java разработчиков писать тесты на Java
и работать с Git
Ежедневные запуски на стендах разработки](https://image.slidesharecdn.com/devopslegacy-legacyisnotexcuseanymore1-170603164347/85/DevOps-SIEBEL-CRM-11-320.jpg)
More Related Content
What's hot (20)
Similar to Петр Клименко. DevOps Трансформация для SIEBEL CRM (20)
More from ScrumTrek (20)
Петр Клименко. DevOps Трансформация для SIEBEL CRM
- 1. DevOps Трансформация для SIEBEL CRM ОПЫТ ВНЕДРЕНИЯ ПРОЦЕССОВ CI/CD НА ПЛАТФОРМЕ БОЛЬШОЙ CRM
- 2. О докладчике Петр Клименко, СБТ Опыт внедрения Siebel: 11 лет
- 3. Предпосылки Внедрение Agile Очень долгие релизы => Постоянная поставка
- 4. Детализация требований Для ускорения релизов была проведена процессная трансформация, но нужна инженерная поддержка: ◦Первичная автоматизация всех рутинных операций ◦Модульные автотесты для ускорения регресса ◦Unit-тесты для разработчика для раннего выявления дефектов ◦Code review для повышения внутреннего и внешнего качества ◦Управление конфигурацией/кодом для инкрементальных поставок
- 5. Ограничения платформы [Siebel CRM] Ограничения унаследованной платформы разработки: Нет версионного контроля Как следствие, нет code review Как следствие, нет инкрементальных поставок Нет Framework для модульных и unit-тестов
- 6. Особенности проекта 5 стендов разработки: ◦3 релизных стенда, ◦Стенд поддержки ◦Стенд для быстрых релизов Выход в про основных релизов: каждые 3 месяца Вывод быстрых релизов: каждый месяц
- 11. Начало борьбы: Unit-тесты Расковыряли API системы Запилили Framework для unit-тестов [Java, jUnit] Обучили не-java разработчиков писать тесты на Java и работать с Git Ежедневные запуски на стендах разработки
- 17. Начало борьбы: Модульные тесты Для UI-тестов: сделали свой Framework на базе Selenium Для тестирования интеграции: используем заглушки Подготовка и проверка данных через Java API Java, TestNG, Selenium, Git
- 18. Продолжение борьбы: управление конфигурацией Родился отдельный продукт: Версионирование конфигурации Диффы сложных конфигурационных объектов Значительный объем конфигурации Алгебра патчей GitFlow для task/feature branches
- 24. Текущие Результаты Быстрый регресс на модульных и unit-тестах Быстрая локализация дефектов в конфигурации Сокращение времени мерджа между стендами разработки Сокращение дефектов мерджа Сокращение времени на сборку и установку поставки на стенда тестирования
- 25. Следующие шаги Docker-изация всех стендов разрботки и тестирования Полная автоматизация установки через Ansible Гибкое разрешение конфликтов одновременной разработки через RocketSiebel
- 28. Унаследованные системы больше не оправдание.