Download to read offline
More Related Content
Similar to Continuous Integration
Continuous Integration
- 1.
- 2. Presented By & INTRODUCTION ContinuousIntegration
- 3. Presented By & Introduction ContinuousIntegration It's an initiative for gathering people interested in Agile, eXtreme Programming (aka: XP), Scrum, Coding, etc. The Idea of XP Days was found at November 2019 and since that we have conducted lots of knowledge sharing meetups and webinars. Agile Arena is an Agile Consulting and Training company. We specialize in agile adoption and transformation for companies and teams through: • Designing their agile adoption programs • Executing our programs and guiding the team through their journey to sustainable agility . • We also provide training for teams and individuals to help them coping with the agility trend in the market.
- 4. Presented By &ContinuousIntegration XP Practices Shared understanding Fine-scale feedback Continuous process Programmer welfare
- 5. Presented By & XPPractices • Continuous Integration • Refactoring • Small releases Continuous Integration Continuous process
- 6. Presented By &ContinuousIntegration
- 7. This Webinar is HeldBy: Mohamed ShaabanSenior Software Engineer
- 8. Presented By & AGENDA •Continuous Integration. • Pipelines and Agents • Technical Debt • Package Management • Build Artifact • SQL Package • Web Deploy • Test Selenium What we’ll be covering this webinar
- 9. Presented By &ContinuousIntegration
- 10. Continuous integration isa development practice that requires developers to integrate code into the shared library several times a day. Each commit is verified by an automated build, allowing teams to detect problems early. Continuous Integration
- 11. Presented By &ContinuousIntegration
- 12. • Improving codequality based on rapid feedback. • Triggering for automated testing for every code change. • Reducing build times for rapid feedback and early detection of problems (risk reduction). • Managing technical debt better and conducting code analysis. • Reducing long, difficult, and bug-inducing merges. • Increasing confidence in code-base health long before production. Rapid feedback for code quality CI Benefits
- 13. • Are developersin your organization committing code multiple times a day to the source control repository? • Are the same developers committing at least once a day to the main code line that's used to publish a code into the test environments? • Are the commits that are done triggering a process of automated build and unit test execution? • Do the developers look at the results of the unit test execution, and a key metric there is code coverage. Are they constantly working towards improving the code coverage from these automated processes? • When the build actually goes red and fails, do the development teams stop what they're doing and fix the build within the next 10 minutes? Do you implement it in right way and gain its benefits?
- 14. Presented By &ContinuousIntegration The Four Pillars of Continuous Integration Source/VersionControl continuous integration system AutomationBuild PackageManagement
- 15. Presented By &ContinuousIntegration
- 16. Presented By &ContinuousIntegration Version Control System
- 17. Why Source Control? Codedoesn’t exist unless it’s committed into source control… Source Control is the fundamental enables of Continuous Delivery!
- 18. Centralized Source ControlSystem Centralized version control systems are based on the idea that there is a single “central” copy of your project somewhere (probably on a server), and programmers will “commit” their changes to this central copy. “Committing” a change simply means recording the change in the central system. Other programmers can then see this change. They can also pull down the change, and the version control tool will automatically update the contents of any files that were changed.
- 19. Centralized Source ControlSystem Work Flow • Pull down any changes other people have made from the central server. • Make your changes, and make sure they work properly. • Commit your changes to the central server, so other programmers can see them.
- 20. Centralized Source ControlSystem TFVC • Strengths • Easley scale for large code base • Granular permission control • Permits monitoring for usage • Allow exclusive file locking • Best used for • Large integrated code base • Audit & Access control down to file level • Hard to merge file types
- 21. Distributed Source ControlSystem distributed version control (also known as distributed revision control) is a form of version control where the complete codebase - including its full history - is mirrored on every developer's computer. This allows branching and merging to be managed automatically, increases speeds of most operations (except for pushing and pulling), improves the ability to work offline, and does not rely on a single location for backups.
- 23. Distributed Source ControlSystem Git • Strengths • Performing actions other than pushing and pulling change sets is extremely fast because the tool only needs to access the hard drive, not a remote server. • Committing new change sets can be done locally without anyone else seeing them. Once you have a group of change sets ready, you can push all of them at once. • Everything but pushing and pulling can be done without an internet connection. So you can work on a plane, and you won’t be forced to commit several bug fixes as one big change set. • Since each programmer has a full copy of the project repository, they can share changes with one or two other people at a time if they want to get some feedback before showing the changes to everyone.
- 24. When sharing acodebase… Co-developing with others in a team • Will my code , • Break other code? • Introduce code quality issues? • Drop the code coverage? • Take on a new dependency? • Will the incoming code, • Break my code? • Introduce code quality issues? • Drop my code coverage? • Take on a new dependency?
- 25. Git Hook • wecould use a Git hook script to automatically build and roll-out our software to our production servers everytime there was a commit on master.
- 26. A successful Gitbranching model By Vincent Driessen on Tuesday, January 05, 2010 The main branches infinite lifetime The Supporting branches Feature Hot Fix Limited lifetime
- 27. A successful Gitbranching model characteristics • Decentralized but centralized • Has 2 main branches with infinite life time • Master : We consider origin/master to be the main branch where the source code of HEAD always reflects a production-ready state. • Develop/Integration: We consider origin/develop to be the main branch where the source code of HEAD always reflects a state with the latest delivered development changes for the next release. • Feature Branch • May branch off from: develop • Must merge back into: develop • Branch naming convention: anything except master, develop, release-*, or hotfix-* • Release Branch • May branch off from: develop • Must merge back into: develop and master • Branch naming convention: release-* • Hotfix Branch • May branch off from: master • Must merge back into: develop and master • Branch naming convention: hotfix-*
- 28.
- 29. Agents • Microsoft-hosted agents •If your pipelines are in Azure Pipelines, then you've got a convenient option to build and deploy using a Microsoft-hosted agent. With Microsoft-hosted agents, maintenance and upgrades are taken care of for you • Self-hosted agents • An agent that you set up and manage on your own to run build and deployment jobs is a self-hosted agent. You can use self-hosted agents in Azure Pipelines. Self-hosted agents give you more control to install dependent software needed for your builds and deployments.
- 30.
- 31.
- 32. Pipelines Demo • .NetFramework pipeline • .Net Core pipeline • Unit test pipeline • Web Deploy pipeline • Angular pipeline • Db project pipeline • Configuration pipeline
- 33.
- 34. Sources and Impactsof Technical Debt • Lack of coding style and standards. • Lack of or poor design of unit test cases. • Ignoring or not understanding object orient design principles. • Monolithic classes and code libraries. • Poorly envisioned use of technology, architecture and approach. (Forgetting that all attributes of the system, affecting maintenance, user experience, scalability, and others, need to be considered). • Over-engineering code (adding or creating code that is not needed, adding custom code when existing libraries are sufficient, or creating layers or components that are not needed). • Insufficient comments and documentation. • Not writing self-documenting code (including class, method and variable names that are descriptive or indicate intent). • Taking shortcuts to meet deadlines. • Leaving dead code in place.
- 35.
- 36. Integrating Other CodeQuality Tools
- 37. Managing Security policies •WhiteSource Bolt • Detects all open source components in your software, without ever scanning your code. It provides you with real-time alerts on vulnerable and outdated open source components and generates comprehensive up-to-date inventory, licenses and security reports with only one click. • OWASP/ZAP • Popular free security tool for helping to identify vulnerabilities during the development process from OWASP. This extension shifts scanning and reporting into the Azure DevOps Pipeline model to enable quick feedback and response from development teams throughout the development life-cycle.
- 38.