МенеджментПідрозділ
Процес релізу
Що відбувається між «код змерджено» і «користувач це має», — а у здоровій команді це рішення, а не подія. Три теми: як планувати реліз, коли не можеш пообіцяти дату; яку модель гілкування витримає ваша швидкість рев’ю; і як записати, що змінилося, для тих, для кого воно змінилося.
Що всередині
Усі сторінки цієї групи — і про що кожна з них.
- Планування релізуРозгортання — не реліз: чотири види фіче-флагів, expand-and-contract і що має перевіряти go/no-go.Фіче-флагиGo / no-go
- Git-стратегія гілкуванняTrunk-based, GitFlow і GitLab Flow чесно порівняні — і чому справжня причина довгих гілок у швидкості рев’ю, а не в моделі.Trunk-basedGitFlow
- ChangelogЧенджлог, release notes і гайд міграції — це три різні документи. Плюс SemVer, 0.y.z і політика застарівання.SemVerЗастарівання
З чого почати
- Релізи — це стресові подіїПланування релізу, зокрема відділення розгортання від релізу. Саме ця зміна знімає більшість стресу.
- Мерджі болючіСторінка про гілкування. Виправлення зазвичай у коротших гілках, а коротші гілки — у швидшому рев’ю.
- Ви публікуєте APIЧенджлог: питання публічного API й політика застарівання — це те, чого справді хочуть ваші споживачі.
Інше в цьому розділі
- МенеджментУправління IT-проєктом — це набір рішень, які перетворюють намір на випущений продукт: що будувати, як розрізати це на роботу, яку справді можна завершити, як команда організовує себе тиждень за тижнем і як результат доходить до користувачів. У розділі 21 тема у пʼяти групах — продуктовий менеджмент, декомпозиція, методології, реліз-процес і формальні фреймворки, — і кожна сторінка дає компроміс за вибором, а не переказ для сертифікаційного іспиту.
- МетодологіїЯк команда вирішує, що будувати далі, у якому порядку і звідки знає, що щось завершено. Девʼять методологій — від двох, за якими більшість справді працює, до чотирьох, що існують, бо однієї команди стало замало. Кожна сторінка описує те, що фреймворк справді визначає — кожну церемонію, роль і артефакт, — а не переказує його, і прямо каже, де він перестає працювати.
- DevOpsЯк довести зміну з машини розробника до працюючої системи — повторювано й без церемоній. Три теми, що складаються одна на одну: пайплайн, що вирішує, чи зміна безпечна; формат образу, який робить «у мене працює» перевірюваним твердженням; і планувальник, що тримає результат запущеним. Кожна сторінка про механізм, а не про синтаксис конфігурації інструмента, — саме механізм і переноситься при зміні інструментів.
Було корисно?
Поділіться з тим, хто працює над тією ж задачею.