EPAM IT Meet Up. Continuous delivery

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 календарных месяца)
Итог

17. 17CONFIDENTIAL
CD !=
P.S.