SlideShare a Scribd company logo
Continuous deployment, або
Як деплоїти 5 раз за день
Андрій Шумада
Про мене
Debitoor.com
Hvz.kiev.ua
eagleeye_s
eagleeye
Ахтунг!
2 дева
2 деви
+ git rebase
Стране нужна … ?
How 2 deploy 5 times per day | Continuos deployment
SCRUM
 Пул задач на 2 тижні
 Реліз кожних 2 тижні, або більше
 Всі працюють в одній вітці (master)
 Стабильность -> release
 Master -> playground.xxx.com
 Release -> staging.xxx.com -> xxx.com
8 девів – master + release
А як насправді?
Реліз запланований на день Х
Зарелізились в день Х + 10
еееее…
Чого затягується реліз?
 Трабли після merge release -> master
 Під кінець спрінта хтось сів рефакторити (фотка мене)
 Фіча велика, не піддається розбиттю на декілька спринтів
 Переоцінили свої сили
 Спочатку недооціинли свої сили.. А потім переоцінили їх…
 Хтось щось поламав.. Всі чекають..
 Мокапи помінялись під кінець спрінта
Всі чекають..
..або пилять наступний спрінт в master
…реліз затягується..
Давайте
 Релізитись частіше
(5 раз в день)
 Не мішати один одному
 Не чекати один одного
Branches
Основні принципи
 Одна фіча – один бранч, в одному пул реквесті
 При конфліктах – master завжди правий
 В мастер попадають бранчі в вигляді одного коміта (--squash) -
легко ревертити
 Вітка завжди повинна містити останній мастер
 QA – тестити треба завжди останній master + feature
 В рамках однієї бранчі працювати в –rebase режимі
Master завжди
правий
Після кожного релізу
master -> featureBranch
Як розібратись що ревертити?
git merge featureBranch - -squash
git commit –m ‘New feature, fixes #43’
Як перевірити, чи девелопер змерджив
master?
#!/bin/sh
echo 'detecting latest master..'
localHistory=`git log -n 50 --pretty=format:"%H"`
latestMaster=`git ls-remote origin master | awk '{print $1;}'`
echo "latest master: $latestMaster"
if echo "$localHistory" | grep -q "$latestMaster"; then
echo "branch has latest master"
else
echo "branch doesn't have latest master"
exit 1
fi
Переваги
 Роблю фічу скільки хочу, час ніколи не піджимає
 Легше знайти винного..
 В разі проблем на продакшені відкатується лише одна фіча
 Не блокуються і не відкатуються інші фічі..
 Фічі появляються швидше в продакшені
 Область тестування завжди обмежена
І це працює!

More Related Content

PPTX
Інформатика 7 клас
PPT
4 клас урок 27 що таке повторення
PPT
4 клас урок 28 створення та виконання алгоритмів з повторенням у визначеному ...
PDF
Як прокачати трьох студентів за п’ять тижнів
PDF
Top 100 Linux Interview Questions and Answers 2014
PDF
Unstoppable releases with kanban
PDF
How to deploy to production 10 times per day v2 for Levi9
PDF
How to deploy to production 10 times a day
Інформатика 7 клас
4 клас урок 27 що таке повторення
4 клас урок 28 створення та виконання алгоритмів з повторенням у визначеному ...
Як прокачати трьох студентів за п’ять тижнів
Top 100 Linux Interview Questions and Answers 2014
Unstoppable releases with kanban
How to deploy to production 10 times per day v2 for Levi9
How to deploy to production 10 times a day
Ad

How 2 deploy 5 times per day | Continuos deployment

  • 1. Continuous deployment, або Як деплоїти 5 раз за день Андрій Шумада
  • 8. SCRUM  Пул задач на 2 тижні  Реліз кожних 2 тижні, або більше  Всі працюють в одній вітці (master)  Стабильность -> release  Master -> playground.xxx.com  Release -> staging.xxx.com -> xxx.com
  • 9. 8 девів – master + release
  • 10. А як насправді? Реліз запланований на день Х Зарелізились в день Х + 10
  • 12. Чого затягується реліз?  Трабли після merge release -> master  Під кінець спрінта хтось сів рефакторити (фотка мене)  Фіча велика, не піддається розбиттю на декілька спринтів  Переоцінили свої сили  Спочатку недооціинли свої сили.. А потім переоцінили їх…  Хтось щось поламав.. Всі чекають..  Мокапи помінялись під кінець спрінта
  • 13. Всі чекають.. ..або пилять наступний спрінт в master …реліз затягується..
  • 14. Давайте  Релізитись частіше (5 раз в день)  Не мішати один одному  Не чекати один одного
  • 16. Основні принципи  Одна фіча – один бранч, в одному пул реквесті  При конфліктах – master завжди правий  В мастер попадають бранчі в вигляді одного коміта (--squash) - легко ревертити  Вітка завжди повинна містити останній мастер  QA – тестити треба завжди останній master + feature  В рамках однієї бранчі працювати в –rebase режимі
  • 17. Master завжди правий Після кожного релізу master -> featureBranch
  • 18. Як розібратись що ревертити? git merge featureBranch - -squash git commit –m ‘New feature, fixes #43’
  • 19. Як перевірити, чи девелопер змерджив master? #!/bin/sh echo 'detecting latest master..' localHistory=`git log -n 50 --pretty=format:"%H"` latestMaster=`git ls-remote origin master | awk '{print $1;}'` echo "latest master: $latestMaster" if echo "$localHistory" | grep -q "$latestMaster"; then echo "branch has latest master" else echo "branch doesn't have latest master" exit 1 fi
  • 20. Переваги  Роблю фічу скільки хочу, час ніколи не піджимає  Легше знайти винного..  В разі проблем на продакшені відкатується лише одна фіча  Не блокуються і не відкатуються інші фічі..  Фічі появляються швидше в продакшені  Область тестування завжди обмежена