МенеджментПідрозділ
Процес релізу
Що відбувається між «код змерджено» і «користувач це має», — а у здоровій команді це рішення, а не подія. Три теми: як планувати реліз, коли не можеш пообіцяти дату; яку модель гілкування витримає ваша швидкість рев’ю; і як записати, що змінилося, для тих, для кого воно змінилося.
Що всередині
Усі сторінки цієї групи — і про що кожна з них.
- Планування релізуГотовий план релізу з етапами за прапорцем: деплой проти релізу, стратегії викочування, шлях назад і чотири провалені релізи.Фіче-флагиCanary
- Git-стратегія гілкуванняШість моделей на одному екрані й п’ять питань, що обирають, — і чому гілки довгими робить швидкість рев’ю, а не модель.Trunk-basedGitFlow
- ChangelogГотовий changelog рядок за рядком: що обіцяє номер версії, записи, за якими можна діяти, депрекація й автоматизація.SemVerДепрекація
З чого почати
- Релізи — це стресові подіїПланування релізу, зокрема відділення розгортання від релізу. Саме ця зміна знімає більшість стресу.
- Мерджі болючіСторінка про гілкування. Виправлення зазвичай у коротших гілках, а коротші гілки — у швидшому рев’ю.
- Ви публікуєте APIЧенджлог: питання публічного API й політика застарівання — це те, чого справді хочуть ваші споживачі.
Інше в цьому розділі
- МенеджментУправління IT-проєктом — це набір рішень, які перетворюють намір на випущений продукт: що будувати, як розрізати це на роботу, яку справді можна завершити, як команда організовує себе тиждень за тижнем і як результат доходить до користувачів. У розділі 25 тем у шести групах — продуктовий менеджмент, декомпозиція, методології, реліз-процес, формальні фреймворки й саме ремесло ведення проєкту, а не метод його ведення, — і кожна сторінка дає компроміс за вибором, а не переказ для сертифікаційного іспиту.
- МетодологіїЯк команда вирішує, що будувати далі, у якому порядку і звідки знає, що щось завершено. Девʼять методологій — від двох, за якими більшість справді працює, до чотирьох, що існують, бо однієї команди стало замало. Кожна сторінка описує те, що фреймворк справді визначає — кожну церемонію, роль і артефакт, — а не переказує його, і прямо каже, де він перестає працювати.
- DevOpsЯк довести зміну з машини розробника до працюючої системи — повторювано й без церемоній. Три теми, що складаються одна на одну: пайплайн, що вирішує, чи зміна безпечна; формат образу, який робить «у мене працює» перевірюваним твердженням; і планувальник, що тримає результат запущеним. Кожна сторінка про механізм, а не про синтаксис конфігурації інструмента, — саме механізм і переноситься при зміні інструментів.
Було корисно?
Поділіться з тим, хто працює над тією ж задачею.