В мене немає інших порад, окрім "валіть звідси", але можу розповісти, як це працює в нормальних компаніях і командах
- є загальне розуміння того, що якісний продукт = щасливі клієнти = більше грошей = стабільність, зріст зп = profit для кожного
- work life balance - у нас фул ремоут, 9 to 5, іноді (досить рідко) буває, шо треба шось задеплоїти outside working hours, якщо це відбувається, компенсують time off 2:1. Інша робота поза робочим часом не пропонується, не стимулюється і не вітається
- no-blame culture: як досягнення, так і пройоби одного належать всій команді в масштабі команди, та всьому engineering відділу в цілому. Будь-які проблеми в результаті мають конструктивний діалог, результатом якого можуть бути process changes, додатковий менторінг і тд
- будь-який комміт у код робиться через pull request, якому для merge потрібно 1 чи 2 approvals. Code review робиться відповідно до задокументованих code standards, в яких є сінтаксис, patterns та інше. У всіх в IDE є готовий xml (для phpstorm/php) або lint (для vscode/js) для автоформату згідно зі стандартами.
- code standards не вибиті на кам'яних скрижалях, вони постійно обговорюються та іноді змінюються в результаті конструктивного діалогу
- архітектура розробляється відділом архітектури; архітектурні рішення передаються девам у вигляді confluence doc + handover meeting. Фідбек від девів береться до уваги і іноді змінює рішення. Рішення щодо інструментарію (мови, фреймворки, БД і тд) приймаються спільно архітекторами і девами.
- є більш менш up to date документація щодо мікросервісів, іх взаємодії, функцій і тд; переважна частина важливих технічних рішень документується
- є автоматизований процес розвертання local dev environment
- під час/після мерджу коду до main/master відбуваються whitesource/mend checks на vulnerabilities та автоматичний білд і деплой у test; під час білду також проходять unit tests, білд фейлиться, якщо юніт тести фейляться
- код, який можна юніт тестити, не апрувиться без юніт тестів (на розсуд апрувера)
- шлях коду виглядає так: local (dev testing) -> test (dev testing) -> uat (QA testing, regression etc) -> demo (smoke tests, performance tests) -> prod (smoke tests)
- код не потрапляє до QA, поки він не протеститься девом на test environment
- код не потрапляє до продакшну, поки він повністю не протестений QA з точки зору функціональності, регресії, перфоманс і тд; для прод деплоя потрібна згода QA та продакту, без них це технично неможливо
- потенційно небезпечні речі (такі, як schema or data migrations в існуючих DB tables) - проходять через процес дискусії та апрува з engineering control board, де обговорюються ризики та їх mitigation, стратегії деплоя і тд
- є customer success, є саппорт. Баги, чи то знайдені самими QA на проді, чи то зарепорчені клієнтами та підтверджені QA - в першу чергу робиться rollback, якщо це можливо. Якщо ні, то client-found reports категоризуються як інцидент, в якого вираховується категорія based on scope + severity. В залежності від категорії, він стає хотфіксом, або пріоритетним тікетом, або звичайним тікетом.
- для хотфіксів і інших задач є процес вибіркової заморозки деплоїв окремих сервісів
- після інциденту пишеться RCA документ (root cause analysis), в якому аналізуються причини, наслідки та інше, в тому числі за 5-whys методикою, цей документ потім презентується автором на наступному ART sync meeting, де ми обговорюємо, як зробити, щоб це не повторилося.
Є більше, але це й так дуже довго 😊 Шось приблизно таке, достатньо, шоб мати уяву - навряд чи це можливо в компанії, де "php jquery та html в одному файлі" і тд
