Якщо хтось ще не помітив, усе рухається в бік Continuous Deployment/Delivery - постійного впровадження, коли ніхто не чекає Релізу, а просто викочує усі зміни на продакшен кожні 11 секунд, як Amazon.
Навіть якщо зараз у вас не так, треба звикати, що все постійно оновлюється і змінюється. Я навіть не здивуюся, якщо скоро випуск і оновлення нових версій мобільних додатків зроблять примусово-обов’язковим, і навіть їм можна буде релізитись що 5 хвилин :-)
Отже, як працюють розробники за Continuous Deployment?
Про це була презентація Андрія Солдатенка (@a_soldatenko):
Extending GitHub Flow with practical testing
Навіть якщо зараз у вас не так, треба звикати, що все постійно оновлюється і змінюється. Я навіть не здивуюся, якщо скоро випуск і оновлення нових версій мобільних додатків зроблять примусово-обов’язковим, і навіть їм можна буде релізитись що 5 хвилин :-)
Отже, як працюють розробники за Continuous Deployment?
Extending GitHub Flow with practical testing
Усі тепер знають, що таке Git Flow (навіть я про це трохи писав). Але для постійних змін він не підходить, бо у нас тепер нема ітерацій, релізів, хот-фіксів. Адаптація до нових реалій має назву Github Flow (за назвою Github’у як компанії, що вперше цей процес задокументувала), ось тут добре описано, що воно таке. У цьому офіційному описі забули вказати, коли вони тестують, і Андрій у своїй презентації виправив цей недолік, назвавши тестування "Practical Testing". Не знаю, чому він вибрав саме це словосполучення, але за контекстом я зрозумів, що це будь-які перевірки і тести, окрім автоматизованих наборів.
Головна відмінність Github Flow від Git Flow у тому, що перед злиттям фіча-гілки з мастером ми відправляємо її, цю фіча-гілку, на продакшен. Якщо воно після цього працює, ми мержимо гілку в мастер. Якщо ні, у нас мастер лишився чистим, і ми відкочуємося, чи радше "перекочуємося" на мастер знову.
Концепція проста, і в Cogniance так роблять вже давно, хоча й не називали це Github Flow.
Все круто! Зміни викочено!
Але якщо ви колись брали участь у релізі, згадайте, що ви робили після того, як новий код був на продакшен серверах, кеш почищено, пару кліків по "головній", чи все не лежить... і.... Ми чекаємо! Чекаємо, доки користувачі зроблять основну роботу з тестування зміненого функціоналу.
А чому це роблять користувачі, а не ми?
Переваги реальних юзерів у наступному:
- вони реальні, а не симульовані
- саме їхній досвід і є кінцевим показником якості нашого продукту
- це ризиковано, бо в разі проблем, спершу дізнаються всі інші, а потім ми
- локалізувати проблему виходячи зі звітів користувачів дуже важко
- Бо це змінить наші робочі дані
- Бо користувачі побачать
і будуть сміятися
Про те, як чуваки тестують на проді у Guardian Media Group, розповів Джон Хейр-Вінтон (@jonhw87).
В тому, що саме вони тестують, нема нічого надзвичайного, це найпріоритетніші для них сценарії: створення, перегляд та видалення контенту.
Але те, що вони запускають цей тестовий набір 3200 разів на день на живому робочому середовищі!
Мої нотатки до презентації Джона:
- Треба ховати тестові дані не тільки від юзерів, але й від звітових систем та інтеграцій (вам повідомлять, якщо ви якусь пропустите :-) )
- Вміст тестових даних має явно казати "Це тестові дані", щоб уникнути подальших проблем
- У цьому мінливому світі, поки 10 разів не впав, тест ще не failed
- Результати завалених тестів зберігаються 48 годин
- Статистика по кожному запуску злінкована з релізами та деплоймент логами
На цьому нарешті все про SeleniumCamp 2017
Дивіться також:
Немає коментарів:
Дописати коментар