. Але навіть в тих трьох місцях, де я працював, спущена зверху всякими просвітленими менеджерами і cost-saving віцепрезидентами мантра "be your own QA" була абсолютно, категорично неправильною.
Так ця мантра і є неправильною. Якщо просто говорити "be your own QA" і більше нічого не робити - то краще не буде, а буде гірше. Але і розподіляти "тут QA, а тут developers" - це теж гірше. Це ж не дихотомія. :)
Для типової розробки я б починав з CI. CD - це набагато важче, але в плані deployment цілком реальна мета - 1-3 деплоймента за добу, не більше 6 годин від коміту до продакшена, в ідеалі - не більше години. Теоретично це можно робити і з окремими QA, але на практиці від підходу "окремі команди перекидають код через паркан" доводиться відмовлятися.
Але це не значить, що ролі QA чи SRE зникають. Вони просто починають виконувати зовсім інші функції.
Контрприклади/edge cases:
* година до продакшену не завжди значить година до кінця деплойменту * коли галузь технічно унеможливлює швидкі зміни (наприклад, firmware development, де прошивку в чипах не можна змінювати "просто так") - то потрібні інші підходи.
Ця "більшість", вона у твоїх спостереженнях, чи за якимись об'єктивними вимірами?
За вимірами. Якщо цікаво - можеш почати з Accelerate, це seminal work. (Там і про тестування, і про infosec є.) Якщо зайде - подивись на щорічні DORA reports.
І я б розрізняв "більшість випадків, які існують" та "більшість випадків, де та чи інша практика є доречною" - це множини, які слабо перетинаються, хоч про дієти мова, хоч про інфосек.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
timeasmymeasure
no subject
Date: 2021-12-31 02:15 am (UTC)Так ця мантра і є неправильною. Якщо просто говорити "be your own QA" і більше нічого не робити - то краще не буде, а буде гірше. Але і розподіляти "тут QA, а тут developers" - це теж гірше. Це ж не дихотомія. :)
Для типової розробки я б починав з CI. CD - це набагато важче, але в плані deployment цілком реальна мета - 1-3 деплоймента за добу, не більше 6 годин від коміту до продакшена, в ідеалі - не більше години. Теоретично це можно робити і з окремими QA, але на практиці від підходу "окремі команди перекидають код через паркан" доводиться відмовлятися.
Але це не значить, що ролі QA чи SRE зникають. Вони просто починають виконувати зовсім інші функції.
Контрприклади/edge cases:
* година до продакшену не завжди значить година до кінця деплойменту
* коли галузь технічно унеможливлює швидкі зміни (наприклад, firmware development, де прошивку в чипах не можна змінювати "просто так") - то потрібні інші підходи.
За вимірами. Якщо цікаво - можеш почати з Accelerate, це seminal work. (Там і про тестування, і про infosec є.) Якщо зайде - подивись на щорічні DORA reports.
І я б розрізняв "більшість випадків, які існують" та "більшість випадків, де та чи інша практика є доречною" - це множини, які слабо перетинаються, хоч про дієти мова, хоч про інфосек.