O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.
Continuous deployment, або
Як деплоїти 5 раз за день
Андрій Шумада
Про мене
Debitoor.com
Hvz.kiev.ua
eagleeye_s
eagleeye
Ахтунг!
2 дева
2 деви
+ git rebase
Стране нужна … ?
SCRUM
 Пул задач на 2 тижні
 Реліз кожних 2 тижні, або більше
 Всі працюють в одній вітці (master)
 Стабильность -> re...
8 девів – master + release
А як насправді?
Реліз запланований на день Х
Зарелізились в день Х + 10
еееее…
Чого затягується реліз?
 Трабли після merge release -> master
 Під кінець спрінта хтось сів рефакторити (фотка мене)
 Ф...
Всі чекають..
..або пилять наступний спрінт в master
…реліз затягується..
Давайте
 Релізитись частіше
(5 раз в день)
 Не мішати один одному
 Не чекати один одного
Branches
Основні принципи
 Одна фіча – один бранч, в одному пул реквесті
 При конфліктах – master завжди правий
 В мастер попада...
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 --pret...
Переваги
 Роблю фічу скільки хочу, час ніколи не піджимає
 Легше знайти винного..
 В разі проблем на продакшені відкату...
І це працює!
How 2 deploy 5 times per day | Continuos deployment
Próximos SlideShares
Carregando em…5
×

How 2 deploy 5 times per day | Continuos deployment

665 visualizações

Publicada em

special for Code'N'Coffee #4

Publicada em: Software

How 2 deploy 5 times per day | Continuos deployment

  1. 1. Continuous deployment, або Як деплоїти 5 раз за день Андрій Шумада
  2. 2. Про мене Debitoor.com Hvz.kiev.ua eagleeye_s eagleeye
  3. 3. Ахтунг!
  4. 4. 2 дева
  5. 5. 2 деви + git rebase
  6. 6. Стране нужна … ?
  7. 7. SCRUM  Пул задач на 2 тижні  Реліз кожних 2 тижні, або більше  Всі працюють в одній вітці (master)  Стабильность -> release  Master -> playground.xxx.com  Release -> staging.xxx.com -> xxx.com
  8. 8. 8 девів – master + release
  9. 9. А як насправді? Реліз запланований на день Х Зарелізились в день Х + 10
  10. 10. еееее…
  11. 11. Чого затягується реліз?  Трабли після merge release -> master  Під кінець спрінта хтось сів рефакторити (фотка мене)  Фіча велика, не піддається розбиттю на декілька спринтів  Переоцінили свої сили  Спочатку недооціинли свої сили.. А потім переоцінили їх…  Хтось щось поламав.. Всі чекають..  Мокапи помінялись під кінець спрінта
  12. 12. Всі чекають.. ..або пилять наступний спрінт в master …реліз затягується..
  13. 13. Давайте  Релізитись частіше (5 раз в день)  Не мішати один одному  Не чекати один одного
  14. 14. Branches
  15. 15. Основні принципи  Одна фіча – один бранч, в одному пул реквесті  При конфліктах – master завжди правий  В мастер попадають бранчі в вигляді одного коміта (--squash) - легко ревертити  Вітка завжди повинна містити останній мастер  QA – тестити треба завжди останній master + feature  В рамках однієї бранчі працювати в –rebase режимі
  16. 16. Master завжди правий Після кожного релізу master -> featureBranch
  17. 17. Як розібратись що ревертити? git merge featureBranch - -squash git commit –m ‘New feature, fixes #43’
  18. 18. Як перевірити, чи девелопер змерджив 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
  19. 19. Переваги  Роблю фічу скільки хочу, час ніколи не піджимає  Легше знайти винного..  В разі проблем на продакшені відкатується лише одна фіча  Не блокуються і не відкатуються інші фічі..  Фічі появляються швидше в продакшені  Область тестування завжди обмежена
  20. 20. І це працює!

×