Звіт із Selenium Camp 2017, про continuous deployment

Якщо хтось ще не помітив, усе рухається в бік Continuous Deployment/Delivery - постійного впровадження, коли ніхто не чекає Релізу, а просто викочує усі зміни на продакшен кожні 11 секунд, як Amazon.
Навіть якщо зараз у вас не так, треба звикати, що все постійно оновлюється і змінюється. Я навіть не здивуюся, якщо скоро випуск і оновлення нових версій мобільних додатків зроблять примусово-обов’язковим, і навіть їм можна буде релізитись що 5 хвилин :-)

Отже, як працюють розробники за Continuous Deployment?

Рівні інтеграції коду та об’єм тестів

Тестування, як вчать книжки, відбувається на трьох рівнях:

• Integration testing
• System testing
• Acceptance testing

Класична V-модель рівням тестування ставить у відповідність стадії розробки ПЗ. Але у теперішніх умовах саме таку відповідність можна робити хіба що для певних продуктових проектів.
Більшість компаній (принаймні, мені відома) все ширше використовують agile, зокрема scrum, де розробка проходить ітераціями, коли на виході кожної має з’являтися "potentially shippable product increment" - готовий до випуску приріст фунціональності, як би самостійна частина ПЗ. Всюди панує Git Flow, модульність, де кожну фічу розробляють незалежною, із можливістю її повного вимкнення на продакшені.

Таким чином, часто кожна фіча вже є окремим продуктом, що пройшов усі стадії розробки. І усі ці рівні тестування відбуваються, або мали б відбуватися, щодня.

Тому, логічніше поставити у відповідність рівням тестування - стан коду, що перевіряється, тобто гілку у системі контролю версій:

• (Feature) Integration testing  ->  feature code branch
• System (Integration) testing  ->  develop code branch
• (System) Acceptance testing  ->  master code branch