Successfully reported this slideshow.

DevOps Fest 2020. Павел Жданов та Никора Никита. Построение процесса CI\CD для opensource проектов

0

Share

Loading in …3
×
1 of 32
1 of 32

DevOps Fest 2020. Павел Жданов та Никора Никита. Построение процесса CI\CD для opensource проектов

0

Share

Хотя на первый взгляд кажется, что нет никакой разницы, в действительности проприетарные и opensource проекты имеют большое отличие в реализации CI\CD process. Разные команды к которым добавляются неучтенные котрибьютеры работают в разных временных зонах, разработка ведется в условиях недостаточной коммуникации. За добавление новых изменений отвечает не один или несколько человек, а консорциум. В результате, процесс внесения изменений слишком затягивается, увеличивая потенциальные конфликты не только в файлах но и бизнес логике. Все эти особенности вносят свое влияние на устройство CI\CD для open source project. Как он устроен мы и расскажем в нашем докладе.

Хотя на первый взгляд кажется, что нет никакой разницы, в действительности проприетарные и opensource проекты имеют большое отличие в реализации CI\CD process. Разные команды к которым добавляются неучтенные котрибьютеры работают в разных временных зонах, разработка ведется в условиях недостаточной коммуникации. За добавление новых изменений отвечает не один или несколько человек, а консорциум. В результате, процесс внесения изменений слишком затягивается, увеличивая потенциальные конфликты не только в файлах но и бизнес логике. Все эти особенности вносят свое влияние на устройство CI\CD для open source project. Как он устроен мы и расскажем в нашем докладе.

More Related Content

Similar to DevOps Fest 2020. Павел Жданов та Никора Никита. Построение процесса CI\CD для opensource проектов

More from DevOps_Fest

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all

DevOps Fest 2020. Павел Жданов та Никора Никита. Построение процесса CI\CD для opensource проектов

  1. 1. Continuous Delivery. ContinuousDevOps. KYIV, 2020 CI/CD в Open Source C++ проектах
  2. 2. Continuous Delivery. ContinuousDevOps. KYIV, 2020 Overview • - Особенности Opensource проектов • - Инструменты для организации CI/CD • - Containerization with docker • - Стандартизация среды разработки (environment) • - Jenkins • - Clustering
  3. 3. Continuous Delivery. ContinuousDevOps. KYIV, 2020
  4. 4. Continuous Delivery. ContinuousDevOps. KYIV, 2020 Особенности Open Source проектов
  5. 5. Continuous Delivery. ContinuousDevOps. KYIV, 2020 Консорциум - SDLC
  6. 6. Continuous Delivery. ContinuousDevOps. KYIV, 2020
  7. 7. Continuous Delivery. ContinuousDevOps. KYIV, 2020 1. Неучтенные контрибьюторы
  8. 8. Continuous Delivery. ContinuousDevOps. KYIV, 2020
  9. 9. Continuous Delivery. ContinuousDevOps. KYIV, 2020
  10. 10. Continuous Delivery. ContinuousDevOps. KYIV, 2020
  11. 11. Continuous Delivery. ContinuousDevOps. KYIV, 2020
  12. 12. Continuous Delivery. ContinuousDevOps. KYIV, 2020 Manticore
  13. 13. Continuous Delivery. ContinuousDevOps. KYIV, 2020 2. Фильтрация изменений - proposals
  14. 14. Continuous Delivery. ContinuousDevOps. KYIV, 2020 3. Много времени на интеграцию кода
  15. 15. Continuous Delivery. ContinuousDevOps. KYIV, 2020 4. Одновременный merge нескольких фич подряд Интеграционный браааанч! .*$^.*
  16. 16. Continuous Delivery. ContinuousDevOps. KYIV, 2020 Добавление фич
  17. 17. Continuous Delivery. ContinuousDevOps. KYIV, 2020 Красивая история коммитов • Commits squashing • Rebase + merge or back merge? • Readable commit messages like “Review answer” 0_o
  18. 18. Continuous Delivery. ContinuousDevOps. KYIV, 2020 Как проходит ревью “Три круга ада” или как я научился предугадывать... • Внутреннее ревью • Ревью с заказчиком • Ревью с еще одним заказчиком … (а так можно было?!)
  19. 19. Continuous Delivery. ContinuousDevOps. KYIV, 2020 5. Работа команд в разных временных зонах
  20. 20. Continuous Delivery. ContinuousDevOps. KYIV, 2020 Необходим стандарт управления и проверок
  21. 21. Continuous Delivery. ContinuousDevOps. KYIV, 2020 Будущее проекта
  22. 22. Continuous Delivery. ContinuousDevOps. KYIV, 2020 Наша роль
  23. 23. Continuous Delivery. ContinuousDevOps. KYIV, 2020 Open Source CICD
  24. 24. Continuous Delivery. ContinuousDevOps. KYIV, 2020
  25. 25. Continuous Delivery. ContinuousDevOps. KYIV, 2020 Branch types: • Develop • Master • Release • Feature • Bugfix
  26. 26. Continuous Delivery. ContinuousDevOps. KYIV, 2020 Continuous Integration • Style check • Build check • Static code analysis check • Dynamic analysis checks • Unit tests check • Smoke automation tests • Regression automation tests
  27. 27. Continuous Delivery. ContinuousDevOps. KYIV, 2020 Jenkins Jobs matrix
  28. 28. Continuous Delivery. ContinuousDevOps. KYIV, 2020 Release Management • Plan release • Build release • User acceptance testing • Prepare release • Deploy release
  29. 29. Continuous Delivery. ContinuousDevOps. KYIV, 2020 • - sdl_infrastructure • - sdl_tools • - sdl_ci • - scripts and other stuff • - sdl_workspace • - docker containers • - config scripts • - sdl_core • - sdl_atf • - sdl_atf_test_scripts • - sdl_evalution Стандартизация среды разработки (environment)
  30. 30. Continuous Delivery. ContinuousDevOps. KYIV, 2020 Clustering with Mesos
  31. 31. Continuous Delivery. ContinuousDevOps. KYIV, 2020
  32. 32. Continuous Delivery. ContinuousDevOps. KYIV, 2020 Once issues and PRs come, it's too late. Reviewing, testing and deploying fixes and new features from your contributors becomes a black hole of time lost. Big mistake

Editor's Notes

  • Master branch was only for released version of our project.
    Release branch was only for bridging the release to master branch. No other branch (even develop) can directly have a pull request to master branch (except for hotfix). Project maintainers don’t need to create a pull request to master branch. This was already done by our CD. Basically our CD check the Pull Request to release branch. If it pass unit test and instrumentation test then CD will create a new tag to release it and it was merged into master. Whenever a new tag created it will also deploy our release.
    Develop contains feature that’s already accepted by project maintainers. Project maintainers need to creating a pull request to release branch to make a release. The CD will manage the deployment when it’s already on release branch.
    Feature branch was contributors working branch. It must be created from current develop branch. When it finished, it also must be merged back to develop by creating a pull request back to develop.
  • https://help.github.com/en/github/managing-your-work-on-github/creating-and-editing-milestones-for-issues-and-pull-requests
  • ×