Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Ähnlich wie DevOps Fest 2020. Павел Жданов та Никора Никита. Построение процесса CI\CD для opensource проектов
Ähnlich wie DevOps Fest 2020. Павел Жданов та Никора Никита. Построение процесса CI\CD для opensource проектов (20)
Mehr von DevOps_Fest
Mehr von DevOps_Fest (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
DevOps Fest 2020. Павел Жданов та Никора Никита. Построение процесса CI\CD для opensource проектов
- 1. Continuous Delivery. ContinuousDevOps. KYIV, 2020 CI/CD в Open Source C++ проектах
- 2. Continuous Delivery. ContinuousDevOps. KYIV, 2020 Overview • - Особенности Opensource проектов • - Инструменты для организации CI/CD • - Containerization with docker • - Стандартизация среды разработки (environment) • - Jenkins • - Clustering
- 3. Continuous Delivery. ContinuousDevOps. KYIV, 2020
- 4. Continuous Delivery. ContinuousDevOps. KYIV, 2020 Особенности Open Source проектов
- 5. Continuous Delivery. ContinuousDevOps. KYIV, 2020 Консорциум - SDLC
- 6. Continuous Delivery. ContinuousDevOps. KYIV, 2020
- 7. Continuous Delivery. ContinuousDevOps. KYIV, 2020 1. Неучтенные контрибьюторы
- 8. Continuous Delivery. ContinuousDevOps. KYIV, 2020
- 9. Continuous Delivery. ContinuousDevOps. KYIV, 2020
- 10. Continuous Delivery. ContinuousDevOps. KYIV, 2020
- 11. Continuous Delivery. ContinuousDevOps. KYIV, 2020
- 12. Continuous Delivery. ContinuousDevOps. KYIV, 2020 Manticore
- 13. Continuous Delivery. ContinuousDevOps. KYIV, 2020 2. Фильтрация изменений - proposals
- 14. Continuous Delivery. ContinuousDevOps. KYIV, 2020 3. Много времени на интеграцию кода
- 15. Continuous Delivery. ContinuousDevOps. KYIV, 2020 4. Одновременный merge нескольких фич подряд Интеграционный браааанч! .*$^.*
- 16. Continuous Delivery. ContinuousDevOps. KYIV, 2020 Добавление фич
- 17. Continuous Delivery. ContinuousDevOps. KYIV, 2020 Красивая история коммитов • Commits squashing • Rebase + merge or back merge? • Readable commit messages like “Review answer” 0_o
- 18. Continuous Delivery. ContinuousDevOps. KYIV, 2020 Как проходит ревью “Три круга ада” или как я научился предугадывать... • Внутреннее ревью • Ревью с заказчиком • Ревью с еще одним заказчиком … (а так можно было?!)
- 19. Continuous Delivery. ContinuousDevOps. KYIV, 2020 5. Работа команд в разных временных зонах
- 20. Continuous Delivery. ContinuousDevOps. KYIV, 2020 Необходим стандарт управления и проверок
- 21. Continuous Delivery. ContinuousDevOps. KYIV, 2020 Будущее проекта
- 22. Continuous Delivery. ContinuousDevOps. KYIV, 2020 Наша роль
- 23. Continuous Delivery. ContinuousDevOps. KYIV, 2020 Open Source CICD
- 24. Continuous Delivery. ContinuousDevOps. KYIV, 2020
- 25. Continuous Delivery. ContinuousDevOps. KYIV, 2020 Branch types: • Develop • Master • Release • Feature • Bugfix
- 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. Continuous Delivery. ContinuousDevOps. KYIV, 2020 Jenkins Jobs matrix
- 28. Continuous Delivery. ContinuousDevOps. KYIV, 2020 Release Management • Plan release • Build release • User acceptance testing • Prepare release • Deploy release
- 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. Continuous Delivery. ContinuousDevOps. KYIV, 2020 Clustering with Mesos
- 31. Continuous Delivery. ContinuousDevOps. KYIV, 2020
- 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
Hinweis der Redaktion
- 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