Можете пояснити ваш термін «нормально відтестовані»? Що це означає по вашому?

Очень странный вывод. Как раз наоборот. Наш релиз цикл отлажен и автоматизирован настолько, что «деплой в прод» это рутинная работа. Я как раз в прошлую пятницу добавлял кеш на один эндпоинт. Через пару часов после мержа вспомнил, что оно ж уже в проде и пошел ради любопытства глянуть метрики какой там хит рейт. Это и есть нормально построенный деплой процесс. Когда никто не бьёт в гонг и не объявляет о начале деплоя и не собирается специальный консилиум на эту ответственную работу

Всі тести автоматизовані. Ніякого людського фактору. Все що клацає людина, можна і треба автоматизувати

dou.ua/forums/topic/51033
они год назад распиливали монолит на распределенный монолит, теперь следствие деплой 40 тикетов на прод

Так это и была цель!

как откатить версию, когда после тебя уже кто-то десяток новых версий задеплоил для меня загадка

Изи. В команде 4-5 инженеров и около 10 сервисов, которые они ведут. Предположим, что прямо сейчас активно идёт работа по трем из них. Это означает, что аж 2 инженера будут работать над одним сервисом одновременно. Каждому нужно написать код, пройти код ревью и задеплоить его. Я к тому, что это очень маловероятно, что после моего комита до момента когда я понял, что что-то сломал, ещё кто-то что-то закинет. Но! Такое было и нет ничего сложного. Я нажимаю реверт комита в мастере, выношу его в ветку и фиксаю там. Благодаря тому, что комиты маленькие оооочень маленькая вероятность, что мы зацепим прям один и тот же код

1. Згідно піраміди тестування в нас їх не супер багато. В середньому десь хвилин 10 і ще 10 е2е тести. Тестові сьюти в нас окремі для кожного сервісу, тобто ми не проганяємо кожен раз абсолютно всі тести
2. 1 стейж-ес-прод. Невеликі сервіси+невелика команда, яка працює з цим сервісом+ доволі швидкі пайплайни приводить до того що прямо одночасно ніхто не деплоїться. Звісно виключення бувають, але дуже рідко
3. Якщо пече, можна просто повернути все на кілька версій назад, а вже потім реверт коміта, але прям таке буває теж доволі рідко. Якщо вже щось вийшло і настільки все не розвалило, що встигли вийти ще кілька версій, то можливо, це щось легше не відкатувати, а огорнути фіча флагом або відразу зафіксити
4. Ми не робимо брекін ченжес в один момент. Тобто всі зміни розраховані на одночасну роботу обох версій. Проблема з чергами в нас є лише при прогонці тестів, щоб гарантувати, що тести пройдуть лише на новій версії. І ось тут ми ще копаємо і шукаємо хороше рішення. Поки що тестуємо лише через хттп

Ну нет. Вообще не так. Это означает, что процесс налажен так, что это для нас рутинная работа. Не бардак, а наоборот четкая слаженность. Почитайте про DORA. Мы минимизировали риски на всех этапах и теперь не отвлекаемся на всю эту фигню с релизами. В какой-то момент при очередном деплое поймал себя на мысли, что сейчас пятница 6 вечера. Просто уже не думаем об этом. Разницы в днях нет. Плохой релиз может выстрелить когда угодно. Пропуская пятницу, все равно не спастись от падения ночью или через пару дней в субботу.
Суть статьи именно в этом

Не зовсім. Мені подобається чергувати по суботах (таке випадає десь раз на кілька місяців), але з моєї практики це найспокійніший день, коли нічого не трапляється. Просто тримаю ноут поруч )
Ось по неділях вже щось дивне відбувається часто, ну а в будні церез активну розробку природньо роботи у чергового багато

Наші клієнти працюють цілодобово. У деяких трафіка у вихідні найбільше. Ціль наших робіт в цій статті — це DORA. Тобто мінімізувати фейл деплої та мінімізувати час відновлення після такого деплою. Тобто зробити всі підготовчі процедури, щоб овертаймів не було.
Я пам’ятаю часи зборки версії, де сидимо до перемоги, поки не викатимо масу змін щоб встигнути до п’ятниці. Щось йде не так і швидко фіксимо. Потім куримо поки тестувальники перевіряють, потім знов фіксимо, а тестувальники курять....
Ось де овертайми

😆 дякую. Треба запам’ятати

Якщо я вас правильно зрозумів, то це та компанія, де після жовтня оголошується код фріз аж до середини січня.

Але ці практики і підходи вже застарілі. Прогрес не стоїть на місці

Моя порада — зробіть ротацію по 8годин на три зміни з оверлапом

Бувають періоди, коли за зміну не трапляється жодного не те що інцидента, а навіть алєрта. От прям живимо тиждень, чергові міняються і все працює як годинник. Але буває таке, що на одній зміні стріляють алєрти без перерви ще і кілька інцидентів трапляється. Тут складно спрогнозувати як краще. Поки що доба.

напишіть про це статтю теж

Так таке було вже. Я в суботу вранці в самих трусах в коридорі (бо до укриття не добіг) ескалював інцидент. І от на дзвінку вже необхідні спеціалісти, за вікном майже без перерви все вибухає аж будинок трясеться, а ми фіксаємо базу карткових бінів тому що в цей день мастеркард прислав нам криві дані про картки ))

блекфрайдей

Тут піймали)
Дійсно, в нас тоді на три дні був код фріз. І це призвело до неприємних наслідків. Тому що наш конвеєр зупинити складно, а запустити знов ще складніше. Коли накопичується велика черга змін

Я пам’ятаю як випустили версію з кривою міграцією в п’ятницю, але помітили, що видалили пів бази вже лише в суботу і довелося відновлювати вручну частинками дані з останнього бекапу ))

Крута історія! ))

Але чи могло бути святкування ДР в середу? А якби так сталося і це була середа вечір? Або навіть ніч

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

Так, авжеж. Ми його використали ще дуже давно тому хай буде ще перша ланка )

Ще про

дублювання запитів, порівняння швидкодії та результатів

В нас це зроблено спеціальними тестами на стейжі. Через те, що стейж-ес-прод, ми відразу на стейжі бачимо, що десь просіли по швидкості

Плюсую про все написане. Тому і написав, що не для всіх це підходить. Але якщо система така, де можна втратити 50, 100 або 200к на рівному місці (в мене на одній з робіт таке було), то задумуєшся, що якщо б вкинув ці 100к в розробку інструментів надійності, міг би ці 200к не втратити. А також вберегти себе і від майбутніх факапів.
А от про п’ятницю: посил цієї статті був не скільки в тому, що «ось які ми безстрашні та любимо ризикувати», а про те, що в нас розробка наблизилась до потоку в якому немає різниці який день тижня. Ми коли деплоїмо, не задумуємось який сьогодні день через те, що ця практика (деплой) стала пересічною

Згоден, це круто в автоматизованих процесах. В нас є складні алєрти, які за допомогою Prophet очикують прогнозовані значення на які система також реагує. Але в цьому розділі більше було за ті кейси, де вся автоматика провалилася, але людина бачить проблему. Тобто має бути ручка

1. В компанії дофіга. В нашій команді близько 10.
2. 5 працюють з мікросервісами і їм супер комфортно і ще 4 з монолітом і їм супер незручно

Так, але це не вирішує проблеми асинхронної взаємодії. Просто конекту до баз недостатньо. В нас купа зв’язків через брокери або колбеки. Кинувши щось у загальний енв, потрібно отримати результат. Тобто сервіси інших команд мають дьорнути наш і цей ріквест/повідомлення мають прийти саме до нашого

droplet1.dev.your.env