XP teams try to keep systems fully integrated at all times, and shorten the feedback cycle to minutes and hours instead of weeks or months. The sooner you know, the sooner you can adapt.
Watch our record for the webinar "Continuous Integration" to explore how Azure DevOps helps us in achieving continuous feedback using continuous integration.
3. Presented By &
Introduction
Continuous Integration
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 &Continuous Integration
XP Practices
Shared
understanding
Fine-scale
feedback
Continuous
process
Programmer
welfare
5. Presented By &
XP Practices
• Continuous Integration
• Refactoring
• Small releases
Continuous Integration
Continuous process
10. Continuous integration is a 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
12. • Improving code quality 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 developers in 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 &Continuous Integration
The Four Pillars of Continuous
Integration
Source/VersionControl
continuous integration system AutomationBuild
PackageManagement
17. Why Source Control?
Code doesn’t exist unless it’s committed into source control…
Source Control is the fundamental enables of Continuous
Delivery!
18. Centralized Source Control System
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 Control System
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 Control System
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 Control System
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 Control System
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 a codebase…
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
• we could 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 Git branching 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 Git branching 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-*
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.
34. Sources and Impacts of 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.
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.