Построение Continuous

Delivery процесса на

примере проекта MOD-PROD

Сборников Андрей

April 4, 2015

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

3CONFIDENTIAL

У нас было:

• Итерация разработки ~ 4 недели

• 10 проектов с огромным количеством связей

• 12 девелоперов

• 4 разных окружения

• Множество common модулей всех сортов и

расцветок

• (!) Большое количество .sql скриптов

создаваемых разработчиками

MOD-PROD структура

4CONFIDENTIAL

MOD-PROD как было раньше

• 2 недели разрабатываем

• 2 недели тестируем

• Тестирование на различных окружениях

• Отдельный бранч для Test & Fix

W 1 W 5

App1 App2

App3App

N

Test &

Fix

W 3

Функциональность разрабатывается отдельно в каждом приложение

Тестирование интегрированных вместе приложений

5CONFIDENTIAL

MOD-PROD как было раньше

• Изменения проверяются локально, без остальных приложений

• БД песочница общая для всех девелоперов

• Jenkins уведомляет об ошибках тестов

• Изменений может быть много, очень много

• Требования могут быть убраны / добавлены во время итерации

GIT

Jenkins

DevSandbox

Feature 1

Task N

Fail notification

run unit tests

App1

Feature 1Feature 2Feature 3Feature 4

...

...Feature X

Task NFeature X

Task A

6CONFIDENTIAL

Проблемы

Разработчики видят только результаты Unit тестов1

Конфликты при изменениях БД (выполнение скриптов не гарантирует

выполнение при развертке)2

Нет проверки взаимодействия приложений3

Долгое ожидание обратной связи от тестирования / аналитиков4

Нет равномерной загруженности команд5

Возможны изменения требований на этапе тестирования6

Долгий процесс, сложно реагировать на изменения7

7CONFIDENTIAL

Continuous Integration (CI)

1. Включим скрипты БД в

цикл CI

2. Пишем более сложные

тесты на взаимодействие

приложений

Результат: проблемы 1,2,3

выглядят решенными.

Очевидные решения

8CONFIDENTIAL

Continuous Delivery (CD) – непрерывное создание готового к поставке продукта

1. Все пункты из CI

2. Включение интеграционных тестов в процесс релиза

3. Использование системы релизов для БД

4. Изменения фокуса команды разработки – мой следующий коммит может сразу

уйти в релиз

5. Частые автоматические релизы после реализации функциональности / по

расписанию

Результат: проблемы 1,2,3,4,5,6,7 выглядят решенными.

Чуть менее очевидные решения

9CONFIDENTIAL

MOD-PROD как стало

• Нет жесткого разделения цикла разработки и цикла тестирования

• После завершения разработки функциональность идет в релиз

• Интеграционное тестирование часть релиз процесса

• Разработчики проверяют функциональность на спец окружении содержащем все приложения

• Отдельный бранч для релиза

App1

App2

App3

AppN

Auto-test-env

run integration tests

W 1W 5

W 3

bug

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 процесса

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

testNexus

create tag

12CONFIDENTIAL

Jenkins Pipeline

1. Выполнение unit тестов

2. Развертка приложений на тестовом сервере (git commit из

п. 1)

3. Выполнение интеграционных тестов

4. Релиз приложения (git commit из п. 1)

5. Релиз БД скриптов этого приложения

13CONFIDENTIAL

1. Настройка Jenkins + GIT на Windows

2. Настройки Jenkins + Maven + Nexus

3. Отсутствие интеграции Nexus -> Jenkins для деплоя

4. Внедрение системы управление БД

5. Нужно высокое тестовое покрытие

6. Изменение фокуса команды

7. Сложный переходный период

Основные трудности

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));

}

15CONFIDENTIAL

Проблемы vs Решения

№ Проблемы Решения

1 Разработчики видят только результаты

Unit тестов

Integration tests

2 Конфликты при изменениях БД Версионирование, правила именование,

тестирование БД on commit

3 Нет проверки взаимодействия

приложений

Доп. окружение со всеми приложениями

+ Integration tests

4 Долгое ожидание обратной связи от

тестирования

Быстрые релизы

5 Нет равномерной загруженности команд Нет выделенного этапа тестирования

6 Возможны изменения требований на

этапе тестирования

Нет выделенного этапа тестирования

7 Долгий процесс, сложно реагировать на

изменения

Процесс ориентирован на постоянное

создание готового к поставке продукта

16CONFIDENTIAL

Высокое покрытие автотестами

Упрощено создание релизов

Легче реагировать на изменения в требованиях во время итерации

Легче делать внезапные «вот очень срочно завтра надо эту штуку»

Время внедрения процесса ~ 10 чел.-дн. (2 календарных месяца)

Итог

17CONFIDENTIAL

CD !=

P.S.