пʼятниця, 3 березня 2017 р.

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

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



Отже, як працюють розробники за Continuous Deployment?
Про це була презентація Андрія Солдатенка (@a_soldatenko):
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 

Дивіться також: