It meetup cd
- 1. Построение Continuous Delivery процесса на примере проекта MOD-PROD Сборников Андрей April 4, 2015
- 2. 2CONFIDENTIAL MOD-PROD MOD-PROD – группа проектов покрывающая полный цикл производства осуществляемого клиентом. Начиная от дизайна продукта, производства и тестирования до доставки заказчику. Технологии: Java, JavaScript + HTML 5, PostgreSQL, GIT, Amazon Cloud, Atlassian Jira Amazon Cloud App 1 App 2 App N DB 2DB 1 User User
- 3. 3CONFIDENTIAL У нас было: • Итерация разработки ~ 4 недели • 10 проектов с огромным количеством связей • 12 девелоперов • 4 разных окружения • Множество common модулей всех сортов и расцветок • (!) Большое количество .sql скриптов создаваемых разработчиками MOD-PROD структура
- 4. 4CONFIDENTIAL MOD-PROD как было раньше • 2 недели разрабатываем • 2 недели тестируем • Тестирование на различных окружениях • Отдельный бранч для Test & Fix W 1 W 5 App1 App2 App3 App N Test & Fix W 3 Функциональность разрабатывается отдельно в каждом приложение Тестирование интегрированных вместе приложений
- 5. 5CONFIDENTIAL MOD-PROD как было раньше • Изменения проверяются локально, без остальных приложений • БД песочница общая для всех девелоперов • Jenkins уведомляет об ошибках тестов • Изменений может быть много, очень много • Требования могут быть убраны / добавлены во время итерации GIT Jenkins Dev Sandbox Feature 1 Task N Fail notification run unit tests App1 Feature 1 Feature 2 Feature 3 Feature 4 ... ... Feature X Task N Feature X Task A
- 6. 6CONFIDENTIAL Проблемы Разработчики видят только результаты Unit тестов1 Конфликты при изменениях БД (выполнение скриптов не гарантирует выполнение при развертке) 2 Нет проверки взаимодействия приложений3 Долгое ожидание обратной связи от тестирования / аналитиков4 Нет равномерной загруженности команд5 Возможны изменения требований на этапе тестирования6 Долгий процесс, сложно реагировать на изменения7
- 7. 7CONFIDENTIAL Continuous Integration (CI) 1. Включим скрипты БД в цикл CI 2. Пишем более сложные тесты на взаимодействие приложений Результат: проблемы 1,2,3 выглядят решенными. Очевидные решения
- 8. 8CONFIDENTIAL Continuous Delivery (CD) – непрерывное создание готового к поставке продукта 1. Все пункты из CI 2. Включение интеграционных тестов в процесс релиза 3. Использование системы релизов для БД 4. Изменения фокуса команды разработки – мой следующий коммит может сразу уйти в релиз 5. Частые автоматические релизы после реализации функциональности / по расписанию Результат: проблемы 1,2,3,4,5,6,7 выглядят решенными. Чуть менее очевидные решения
- 9. 9CONFIDENTIAL MOD-PROD как стало • Нет жесткого разделения цикла разработки и цикла тестирования • После завершения разработки функциональность идет в релиз • Интеграционное тестирование часть релиз процесса • Разработчики проверяют функциональность на спец окружении содержащем все приложения • Отдельный бранч для релиза App 1 App 2 App 3 App N Auto- test-env run integration tests W 1 W 5 W 3 bug
- 10. 10CONFIDENTIAL Для приготовления CD нам понадобятся: • CI сервер: Jenkins (Git plugin, Maven plugin,Git parameter, Delivery Pipeline plugin, Parameterized Trigger plugin) • Система хранения артефактов: Nexus • Репозиторий: Git • Создание релизов: Maven release plugin • Версионирование БД: Flyway • Тестовое окружение: Auto-test srv (App Server + DB) Построение CD процесса
- 11. 11CONFIDENTIAL CD структура глазами разработчика • Для каждого коммита БД скриптов проводится тестовый апдейт БД • Последние версии приложений всегда доступны на авто-тест сервере • Релизим только то, что прошло авто-тесты • В случае неудачи - уведомления почтой • Все релизы хранятся в Nexus • Для каждого релиза создается Git tag • Для удачных релизов можно создавать release notes GIT Jenkins Feature 1 Task N Fail notification run unit tests Auto-test DB test migration on commit Auto- test Srv Deploy & Run Integration test Nexus create tag
- 12. 12CONFIDENTIAL Jenkins Pipeline 1. Выполнение unit тестов 2. Развертка приложений на тестовом сервере (git commit из п. 1) 3. Выполнение интеграционных тестов 4. Релиз приложения (git commit из п. 1) 5. Релиз БД скриптов этого приложения
- 13. 13CONFIDENTIAL 1. Настройка Jenkins + GIT на Windows 2. Настройки Jenkins + Maven + Nexus 3. Отсутствие интеграции Nexus -> Jenkins для деплоя 4. Внедрение системы управление БД 5. Нужно высокое тестовое покрытие 6. Изменение фокуса команды 7. Сложный переходный период Основные трудности
- 14. 14CONFIDENTIAL «Полуитеграционные» тесты 1. Тестируется взаимодействие с реальной БД 2. Возможность тестировать бизнес-логику 3. Возможность строить сложные сценарии тестирования 4. Откат транзакций по окончанию теста – нет мусора в бд В случае Java EE можно воспользоваться Arquillian или Spring + Java EE @RunWith(SpringJUnit4ClassRunner.class) @ContextConfiguration({ "classpath:test-applicationContext-web.xml", "classpath:test-applicationContext-security.xml", "classpath:test-applicationContext.xml"}) @WebAppConfiguration() public class ControllerTest { public static final String REST_API_SEARCH_REQUEST = "/some/address"; public static final String APPLICATION_JSON_CHARSET_UTF_8 = "application/json;charset=UTF-8"; @Autowired private LotManager lotManager; @Test @Transactional(propagation = Propagation.REQUIRES_NEW) public void testSearch() throws Exception { //Вызов REST сервиса ResultActions loadActions = mvc.perform(MockMvcRequestBuilders .post(REST_API_SEARCH_REQUEST) .contentType(MediaType.APPLICATION_JSON) .content(objectMapper.writeValueAsBytes(Arrays.asList(MyVO.class)))) .andExpect(MockMvcResultMatchers.status().isOk()) .andExpect(MockMvcResultMatchers.content().contentType(APPLICATION_JSON_CHARSET_UTF_8)); loadActions.andDo(MockMvcResultHandlers.print()); //Обработка REST сервиса List<ResponseInfoVO> loadResponse = objectMapper.readValue( loadActions.andReturn().getResponse().getContentAsString(), typeFactory.constructCollectionType(List.class, ResponseInfoVO.class)); }
- 15. 15CONFIDENTIAL Проблемы vs Решения № Проблемы Решения 1 Разработчики видят только результаты Unit тестов Integration tests 2 Конфликты при изменениях БД Версионирование, правила именование, тестирование БД on commit 3 Нет проверки взаимодействия приложений Доп. окружение со всеми приложениями + Integration tests 4 Долгое ожидание обратной связи от тестирования Быстрые релизы 5 Нет равномерной загруженности команд Нет выделенного этапа тестирования 6 Возможны изменения требований на этапе тестирования Нет выделенного этапа тестирования 7 Долгий процесс, сложно реагировать на изменения Процесс ориентирован на постоянное создание готового к поставке продукта
- 16. 16CONFIDENTIAL Высокое покрытие автотестами Упрощено создание релизов Легче реагировать на изменения в требованиях во время итерации Легче делать внезапные «вот очень срочно завтра надо эту штуку» Время внедрения процесса ~ 10 чел.-дн. (2 календарных месяца) Итог