DEVOPSNOTES

Unit1

1. IntroductiontoSDLC

SoftwareDevelopmentLifeCycle(SDLC)

A software life cycle model (also termed process model) is a pictorial and diagrammatic
representationofthesoftwarelifecycle. Alifecycle modelrepresentsallthe methodsrequiredto
makeasoftwareproducttransitthroughitslifecyclestages.Italsocapturesthestructureinwhich these
methods are to be undertaken.

Stage1:Planningandrequirement analysis

RequirementAnalysisisthe mostimportantandnecessarystage inSDLC.

The senior members of the team perform it with inputs from all the stakeholders and domain
experts or SMEs in the industry.

Planningforthequalityassurancerequirementsandidentificationsoftherisksassociatedwiththe
projects is also done at this stage.
Business analyst and Project organizer set up a meeting with the client to gather all the data like
what the customer wants to build, who will be the end user, what is the objective ofthe product.
Before creating a product, a core understanding or knowledge of the product is very necessary.

For Example, A client wants to have an application which concerns money transactions. In this
method,therequirementhastobepreciselikewhatkindofoperationswillbedone,howitwillbe done, in
which currency it will be done, etc.

Once the required function is done, an analysis is complete with auditing the feasibility of the
growthof a product. In case of anyambiguity, a signal is set up for further discussion.

Once the requirement is understood, the SRS (SoftwareRequirement Specification) document is

created. The developers should thoroughly follow this document and also should be reviewed by
the customer for future reference.

Stage2: DefiningRequirements

Once the requirement analysis is done, the next stage is to certainly represent and document the
software requirements and get them accepted from the project stakeholders.

This is accomplished through "SRS"- Software Requirement Specification document which

containsalltheproductrequirementstobeconstructedanddevelopedduringtheprojectlifecycle.

Stage3:DesigningtheSoftware

The next phase isaboutto bring downallthe knowledge ofrequirements, analysis, and designof the
software project. This phase is the product ofthe last two, like inputs fromthe customer and
requirement gathering.

Stage4: Developing theproject

In this phase of SDLC, the actual development begins, and the programming is built. The
implementation ofdesign begins concerning writing code. Developers have to follow the coding
guidelines described by their management and programming tools like compilers, interpreters,
debuggers, etc. are used to develop and implement the code.

Stage5:Testing

Afterthecodeisgenerated,it istestedagainsttherequirementsto makesurethattheproductsare solving

the needs addressed and gathered during the requirements stage.
Duringthisstage, unittesting,integrationtesting,systemtesting,acceptancetestingaredone.

Stage6:Deployment

Oncethesoftwareiscertified, andnobugsorerrorsarestated,thenitisdeployed.

Thenbasedontheassessment,thesoftwaremaybereleasedasitisorwithsuggestedenhancement in the
object segment.

Afterthesoftwareisdeployed,thenitsmaintenancebegins.
Stage7:Maintenance

Once when the client starts using the developed systems, then the real issues come up and
requirements to be solved from time to time.

Thisprocedurewherethecareistakenforthedevelopedproductisknownasmaintenance.

Waterfallmodel

WinstonRoyceintroducedtheWaterfallModelin1970.Thismodelhasfivephases:Requirements
analysisandspecification,design,implementation,andunittesting,integrationandsystemtesting, and
operation and maintenance. The steps always follow in this order and do not overlap. The
developer must complete every phase before the next phase begins. This model is named
"Waterfall Model", because its diagrammatic representation resembles a cascade of waterfalls.

1. Requirements analysis and specification phase: The aim of this phase is to understand the
exact requirements of the customer and to document them properly. Both the customer and the
softwaredeveloperworktogethersoastodocumentallthefunctions,performance,andinterfacing
requirementofthesoftware.Itdescribesthe"what"ofthesystemtobeproducedandnot"how."In this
phase, a large document called Software Requirement Specification (SRS)document is
createdwhichcontainedadetaileddescriptionofwhatthesystemwilldointhecommonlanguage.

2. DesignPhase:ThisphaseaimstotransformtherequirementsgatheredintheSRSintoasuitable form
which permits further coding in a programming language. It defines the overall software
architecture together with high level and detailed design. All this work is documented as a
Software Design Document (SDD).

3. Implementation and unit testing: During this phase, design is implemented. If the SDD is
complete, the implementation or coding phase proceeds smoothly, because all the information
needed by software developers is contained in the SDd

During testing, the code is thoroughly examined and modified. Small modules are tested in
isolationinitially.Afterthatthese modulesaretestedbywritingsomeoverheadcodetocheckthe
interaction between these modules and the flow of intermediate output.

4. IntegrationandSystemTesting:Thisphase ishighlycrucialasthequalityoftheendproduct
isdeterminedbytheeffectivenessofthetestingcarriedout.Thebetteroutputwillleadtosatisfied
customers, lower maintenance costs, and accurate results. Unit testing determines the efficiency
of individual modules. However, in this phase, the modules are tested for their interactions with
each other and with the system.

5. Operationandmaintenancephase:Maintenanceisthetaskperformedbyeveryuseroncethe
software has been delivered to the customer, installed, and operational.
AdvantagesofWaterfallmodel
o This modelis simple to implement also the numberofresourcesthat arerequired for it is
minimal.
o The requirements are simple and explicitly declared; they remain unchanged during the
entire project development.
o Thestartandendpointsforeachphaseisfixed, whichmakesiteasytocoverprogress.
o Thereleasedateforthecompleteproduct,aswellasitsfinalcost,canbedeterminedbefore
development.
o Itgiveseasytocontrolandclarityforthecustomer duetoastrictreporting system.

DisadvantagesofWaterfallmodel
o Inthismodel,theriskfactorishigher,sothismodelisnotsuitableformoresignificantand
complex projects.
o Thismodelcannotacceptthechangesinrequirementsduringdevelopment.
o It becomestoughto go back to the phase. For example, ifthe applicationhas now shifted
tothecodingphase,andthereisachangeinrequirement,Itbecomestoughtogobackand change
it.
o Sincethetestingdoneatalaterstage,itdoesnotallowidentifyingthechallengesandrisks in the
earlier phase, so the risk reduction strategy is difficult to prepare.

Agile development
TheAgilewheelofwheels
 ThereareseveraldifferentcyclesinAgiledevelopment,fromthePortfoliolevel
throughtotheScrumandKanbancyclesanddowntotheContinuousIntegration
 cycle.
 Kanbanemphasizesthe24-hourcycleandispopularinoperations teams.
 Scrumcyclescanbebetweentwotofourweeksandareoftenusedby development
teams using the Scrum Agile process.
 Longer cycles are also common and are called ProgramIncrements, which span
severalScrumSprintcycles,inScaledAgileFramework.

Portfolio
Scrum kanban

TheAgilewheelofwheels
DevOpsmust beabletosupport all thesecycles. Thisisquitenatural giventhe central
theme of DevOps: cooperation between disciplines in an Agile organization.
The most obvious and measurably concrete benefits of DevOps occur in the shorter
cycles, which in turn make the longer cycles more efficient.
HerearesomeexamplesofwhenDevOpscanbenefitAgilecycles:
 Deployment systems, maintained by DevOps engineers, make the deliveriesat
the endof Scrumcyclesfaster andmore efficient. These can take placewitha
periodicity oftwo to fourweeks.
 In organizations where deployments are done mostly by hand, the timeto
deploy can be several days. Organizations that have these inefficient
deployment processes will benefit greatly from a DevOps mindset.
 TheKanbancycleis24hours,andit'sthereforeobviousthatthedeploymentcycle
needs to be much faster than that if we are to succeed with Kanban.
 Awell-designedDevOpsContinuousDelivery pipelinecandeploy codefrom
being committed to the code repository to production in the order ofminutes,
depending on the size of the change.

 Anagile methodologyisan iterative approachto software development. Eachiterationof

agile methodology takes a short time interval of 1 to 4 weeks.

 The agile development processisaligned to deliverthe changing business requirement. It

distributes the software with faster and fewer changes.

 Thesingle-phasesoftwaredevelopmenttakes6to18months. Insingle-phasedevelopment, all

 the requirement gathering and risks management factors are predicted initially.

 Theagilesoftwaredevelopmentprocessfrequentlytakesthefeedbackofworkableproduct. The
workable product is delivered within 1 to 4 weeks of iteration.

BewarethecargocultAgile fallacy
 It is very important that we keep track of our goals and continuously question
whetherwearedoingtherightthingandarestillontherighttrack.Thisiscentral to all
Agile thinking.
 It is,however, somethingthat is manifestlyvery hardto doinpractice. It is easy to
wind up as followers of the cargo cults.
 When constructing deployment pipelines, forexample, keep inmind whywe
arebuilding them in the first place.
 The goal is to allow people to interact with new systems faster and with less
work. This, in turn, helps people with different rolesinteract with each other
more efficiently and with less turnaround.
 If, on the other hand, we build a pipeline that only helps one group of
peopleachievetheirgoals, forinstance, theoperationspersonnel, wehave
failed to achieve our basic goal.
  While thisisnot an exactscience,itpays tobearin mind thatAgilecycles,such as the
sprintcyclein the Scrum Agilemethod, normally have amethod to deal withthis
situation. In Scrum, this is called the sprint retrospective, where the team
getstogetherand discusses what went welland what could have gone betterduring
thesprint.
 Spend some time here to make sure you are doing the right thing in your daily
work.
 A common problem here is that the output from the sprint retrospective isn't really
acted upon. This, in turn, may be caused by the unfortunate fact that the identified
problems were really caused by some other part of the organization that you don't
communicate well with.
 Therefore, these problems come up again and again in the retrospectives and are
never remedied.
 Ifyourecognizethatyourteamisinthissituation,youwillbenefitfromtheDevOps
 approachsinceitemphasizescooperationbetweenrolesintheorganization.
 Tosummarize, trytousethemechanismsprovidedintheAgilemethodsinyour
methodsthemselves.
 IfyouareusingScrum,usethesprintretrospectivemechanismtocapturepotential
improvements.

IntroductiontoDevOps
What is DevOps?
 theDevOpsisthecombinationoftwowords,oneisDevelopment andotherisOperations. It is a
culture to promotethe development and operation process collectively.

 DevOpsisaprocessthatimprovesapplicationDeliverybyensuringautomation,quality,
continuous integration and continuous monitoring.

 DevOps is about People, Process and Tools that produces a high-quality software with
minimum cost.

 DevOpshasbeendescribedvariouslyasaculture,amindset,aframeworkandamovement that
collaborates different teams in IT industry with single pipe line stream.

 DevOps is the practice of operations and development engineers participating together in

the entire service lifecycle, from design through the development process to production
support.

 TheDevOps will help usto learnDevOps basicsandprovidedepthknowledgeofvarious

DevOpstoolssuchasGit,Ansible,Docker,Puppet,Jenkins,Chef,Nagios,and Kubernetes.

 DevOpsincorporatesabunchofprocedureswhichfacilitateanorganizedworkflowwithin a
business concern, such as Continuous Integration/ Continuous Delivery (CI/CD),
Infrastructure as Code (IAC) and Configuration Management (CM). These help
organizationsrealizeremarkablesavingsoncostwithoutcompromisingonproductivityor
quality.

 DevOpsHistory

 TheoriginofthewordDevOpsandtheearlydaysoftheDevOpsmovement can
betrackedratherprecisely:PatrickDeboisisasoftwaredeveloperandconsultant with
experience in many fields within IT.
 He was frustrated with the divide betweendevelopers and operations personnel.
Hetriedgettingpeopleinterestedinthe problemat conferences,but there wasn't
much interest initially.
 In2009,therewasawell-receivedtalkattheO'ReillyVelocityConference:"10+
Deploys per Day: Dev and Ops Cooperation at Flickr." Patrick then decided to
organize an event in Ghent, Belgium, called DevOpsDays. This time, there was
muchinterest, and the conference was a success.
  The name"DevOpsDays" struck a chord, and the conference has become a
recurring event. DevOpsDays was abbreviated to "DevOps" in conversations on
Twitter and various Internet forums.

WhyDevOps?

Beforegoingfurther,weneedtounderstandwhyweneedtheDevOpsover theothermethods.

o Theoperationanddevelopment teamworkedincomplete isolation.

o Afterthedesign-build,thetestinganddeployment areperformedrespectively.That'swhy they
consumed more time than actual build cycles.
o Without the use of DevOps, the team members are spending alargeamountof time
ondesigning, testing, and deploying instead of building the project.
o Manualcodedeploymentleadsto humanerrorsinproduction.
o Coding and operation teams have their separate timelines and are not in synch,
causingfurther delays.

 DevOpsWork flows:

 The followingdiagramshowsthefundamentallifecyclephasesofDevOps.
ThefollowingdiagramshowstheDevOpsworkflow:
 An engineer with a DevOps mindset, on the other hand, will immediately
recognizeall development team, quality assurance team and operations team
systems as being workflow systems with similar properties.
 It should be possible for everyone in the three different teams to use the same
system, perhaps tweaked to generate different views for the different roles.
 A further benefit wouldbe smaller maintenance costs, since three systems are
replaced by one.
 AnothercoregoalofDevOpsisautomationandContinuousDelivery.Simply put,
automating repetitive and tedious tasks leaves more time for human
interaction, where true value can be created.
Howfastisfast DevOps?
 TheturnaroundforDevOpsprocessesmustbe fast.
 We need to consider time to market in the larger perspective, and simply stay
focused onourtasksinthe smaller perspective. This line of thought is also held by
the Continuous Delivery movement.
 As with many things Agile, many of the ideas in DevOps and Continuous
Deliveryareinfactdifferentnamesofthesamebasicconcepts.Therereallyisn't any
contention between the two concepts; they are two sides of the same coin.
 DevOps engineers work on making enterprise processes faster, more efficient,
andmore reliable. Repetitive manual labor, which is error prone, is removed
wheneverpossible.
 Doingnothingfasterisofnousetoanyone.Instead,wemustkeeptrack of
delivering increased business value.

DevOpsandITIL

ITILstandforInformationTechnologyInfrastructureLibrary.

It is a framework which helps the IT professionals for delivering the best services of IT. This
framework is a set of best practices to create and improve the process of ITSM (IT Service
Management). It provides a framework within an organization, which helps in planning,
measuring, and implementing the services of IT.

Themainmotiveofthisframeworkisthattheresourcesareusedinsuchawaysothatthecustomer get the

better services and business get the profit.

Itisasetofstandardsand acollectionofbestpractices guidelines.

ServiceLifecycleinITIL
1. ServiceStrategy.
2. ServiceDesign.
3. ServiceTransition.
4. ServiceOperation.
5. ContinualService Improvement.

1. ServiceStrategy

 Service Strategyis the first and initial stage in the lifecycle of the ITIL framework. The
mainaimofthisstageisthat itoffersastrategyonthebasisofthecurrent marketscenario and
business perspective for the services of IT.

 This stage mainly defines the plans, position, patters, and perspective which are required
for a service provider. It establishes the principles and policies which guide the whole
lifecycle of IT service.

 Following are the various essential services or processes which comes under the Service
Strategy stage:

o FinancialManagement
o DemandManagement
o ServicePortfolioManagement
o BusinessRelationshipManagement
o StrategyManagement

2. ServiceDesign

 ItisthesecondphaseorastageinthelifecycleofaserviceintheframeworkofITIL.This
stageprovidestheblueprint fortheITservices.Themaingoalofthisstageistodesignthe new IT
services. We can also change the existing services in this stage.

 Following are the various essential services or processes which comes under the Service
Design stage:

o ServiceLevelManagement
o CapacityManagement
o AvailabilityManagement
 o RiskManagement
o ServiceContinuityManagement
o ServiceCatalogue Management
o InformationSecurityManagement
o SupplierManagement
o ComplianceManagement
o Architecture Management

3. ServiceTransition

 ServiceTransitionisthethirdstageinthelifecycleofITILManagementFramework.

 The main goalof this stage is to build, test, and develop the new or modified services of
IT.Thisstageofservicelifecyclemanagestheriskstotheexistingservices.Italsocertifies that
the value of a business is obtained.

 This stage also makes sure that the new and changed IT services meet the expectation of
thebusinessasdefined intheprevioustwostagesofservicestrategyandservicedesignin the
lifecycle.
  It canalso easily manage or maintains the transitionofnew or modified IT services from
the Service Design stage to Service Operation stage.

 TherearefollowingvariousessentialservicesorprocesseswhichcomesundertheService
Transition stage:

o ChangeManagement
o ReleaseandDeploymentManagement
o ServiceAsset andConfigurationManagement
o KnowledgeManagement
o ProjectManagement(TransitionPlanningandSupport)
o ServiceValidationand Testing
o ChangeEvaluation

4. ServiceOperations

 Service Operations is the fourth stage in the lifecycle of ITIL. This stage provides the
guidelines about howto maintain and manage the stability in services ofIT, which helps in
achieving the agreed level targets of service delivery.

 This stage is also responsible for monitoring the services ofIT and fulfilling the requests.
Inthisstage,alltheplansoftransitionanddesignaremeasuredandexecutedfortheactual
efficiency.Itisalsoresponsibleforresolvingtheincidentsandcarryingouttheoperational tasks.

 Therearefollowingvariousessentialservicesorprocesseswhichcomesunderthestageof
Service Operations:

o EventManagement
o AccessManagement
o ProblemManagement
o IncidentManagement
o ApplicationManagement
o TechnicalManagement
 5. ContinualServiceImprovement(CSI)

 ItisthefifthstageinthelifecycleofITILservice.Thisstagehelpstoidentifyand implement
strategies, which is used for providing better services in future.

 Followingarethevariousobjectivesor goalsunderthisCSI:

o Itimprovesthequalityservicesbylearningfromthepastfailures.
o Italsohelpsinanalyzingandreviewingtheimprovementopportunitiesineveryphase of the
service lifecycle.
o Italsoevaluatestheservice levelachievementresults.
o Italso describes the best guidelines to achieve the large-scale improvements in
thequality of service.
o Italso helps in describing the concept of KPI, which is a process metrics-driven for
evaluating and reviewing the performance of the services.

Therearefollowingvariousessentialservicesorprocesseswhichcomesunder thestageofCSI:

o ServiceReview
o ProcessEvaluation
o DefinitionofCSIInitiatives
o MonitoringofCSIInitiatives

Advantages of ITIL

Followingarethevariousadvantagesor benefitsofITIL:

1. OneofthebestadvantagesofITIListhatithelps inincreasingthecustomer satisfaction.

2. Itallows managerstoimprovethedecision-making process.
3. Itisalsousedforcreatingtheclear structureofanorganization.
4. Italsohelps managersbycontrollingtheinfrastructureservices.
5. Itimprovestheinteractionbetweenthecustomersandtheservice provider.
6. Withthehelpofthisframework,servicedeliveryisalsoimproved.
7. Itestablishesthe frameworkofITSMforthe organization.
 TheDevOpsprocessandContinuousDelivery(CD) Pipeline

WhenweworkwithDevOps, weworkwithlargeandcomplexprocesses ina large andcomplex context.

AnexampleofaContinuousDeliverypipeline ina largeorganizationis introducedinthe following image:

 Thedevelopers
 Thedevelopers(onthefarleftinthefigure)workontheir
workstations.Theydevelop code and needmany toolsto be efficient.
 ThefollowingdetailfromthepreviouslargerContinuousDelivery
pipelineoverview illustrates the development team.
 Ideally, they would each have production-like environments available to work
withlocally on their workstations or laptops.
 Dependingonthetypeofsoftwarethatisbeingdeveloped,thismightactuallybe
possible, but it's more common to simulate,or rather, mock, the parts of the
production environments that are hard to replicate.
 Thismight,forexample,bethecase for dependencies such asexternal payment
systems or phone hardware.
 a specific version of the Java Development Kit and an integrated
developmentenvironment(IDE),suchasEclipse.IfyouworkwithPython, you
might package a specific Python version, and so on.
 Keep in mind that we essentially need two or more separately maintained
environments. The preceding developer environment consists of all the
developmenttools we need. These will not be installed on the test or production
systems. Further, the developers also need some way to deploy their code in a
production-like way.
 This can be a virtual machine provisioned with Vagrant running on the
developer'smachine, a cloud instance running on AWS, or a Docker container:
there are many ways to solve this problem.
 TheRevisionControlSystem
 Therevisioncontrolsystemisoftentheheartofthedevelopment environment.
 The code that forms the organization's software products is stored here. It is
alsocommon to store the configurations that form the infrastructure here.
 Ifyouare working with hardware development, then the designs might also
be stored in the revision control system.
 The following image shows the systems dealing with code, Continuous
Integration,and artifact storage in the Continuous Delivery pipeline in greater
detail:
 Thebuildserver
 Thebuildserverisconceptuallysimple.Itmightbeseenasaglorifiedeggtimer that
 buildsyoursourcecodeatregularintervalsorondifferenttriggers.

 Themostcommonusagepatternistohavethebuildserverlistentochangesin the
revision control system.

 Whenachangeisnoticed,thebuildserverupdatesitslocalcopyofthe source from

the revision control system. Then, it builds the source and performs optional
tests to verify the quality of the changes. This process is called Continuous
Integration.

 TheArtifactRepository
 Whenthebuildserverhasverifiedthequalityofthecodeandcompiledit
intodeliverables, it is useful to store the compiled binary artifacts in a
repository.
 Thisisnormallynotthesameasthe revisioncontrol system.
 In essence, these binary code repositories are filesystems that are accessible over
theHTTPprotocol.Normally,theyprovidefeaturesforsearchingandindexing
 aswellasstoringmetadata,suchasvarioustypeidentifiersandversion information
about the artifacts.
 AmazonS3(SimpleStorageService)isakey-valuedatastorethatcanbeused to
store binary artifacts.
 Somebuildsystems,suchasAtlassianBamboo, canuseAmazonS3tostore
artifacts.
 TheS3protocolisopen,andthereareopensourceimplementationsthatcanbe
deployed inside your own network.
 Packagemanagersarealsoartifactrepositoriesattheircore.

 Packagemanagers
Linuxserversusuallyemploysystemsfordeploymentthataresimilarinprinciplebut have
some differences in practice.
 RedHat-likesystemsuseapackageformatcalledRPM.Debian-likesystems
usethe.debformat, whichisadifferent packageformat withsimilar abilities.
 Thedeliverablescanthenbeinstalledonserverswithacommandthatfetches them
from a binary repository. These commands are called package managers.
 OnRedHatsystems,thecommandiscalledyum,or,morerecently,
dnf.On Debian-like systems, it is called aptitude /dpkg.
 The great benefit of these package management systems is that it is easy to install
andupgradeapackage;dependenciesareinstalledautomatically.

 Ifyoudon'thaveamore advancedsysteminplace,itwouldbe feasibletologin

toeachserverremotelyandthentype yumupgradeoneachone. Thenewest packages
would then be fetched from the binary repository and installed.
 Ofcourse, as we willsee, we do indeed have more advanced systems of
deploymentavailable;therefore,wewon'tneedtoperformmanualupgrades.
 Testenvironments
After the build server has stored the artifacts in the binary repository, they can be installed
from there into test environments.
Thefollowingfigureshowsthetestsystemsingreaterdetail:
  Test environments should normally attempt to be as production-like as is feasible.
Therefore, it is desirable that the they be installed and configured with the same
methods as production servers.

Staging/production

 Staging environments are the last line of test environments. They are
interchangeablewith production environments.
 You install your new releases on the staging servers,check that everything
works, andthenswapoutyouroldproductionserversand replacethemwiththe
staging servers, which will then become the new production servers. This is
sometimes called the blue-green deployment strategy.
 The exact details of how to perform this style of deployment depend on the
productbeingdeployed.Sometimes,itisnotpossibletohaveseveralproduction
systems running in parallel, usually because production systems are very
expensive.
 Attheotherendofthespectrum,wemighthave manyhundreds ofproduction
systems in a pool.
  Wecanthengraduallyroll outnewreleasesinthepool.Logged-inusers stay with
the version running on the server they are logged in to.
 Newuserslogintoserversrunningnewversionsofthesoftware.
ThefollowingdetailfromthelargerContinuousDeliveryimageshowsthefinal systems and
roles involved:

 Releasemanagement
 Wehavesofarassumedthatthereleaseprocessismostlyautomatic.Thisis
thedream scenario for people working with DevOps.
 Thisdreamscenarioisachallengetoachieveintherealworld.Onereasonfor this is
that it is usually hard to reach the level of test automation needed in order to
have complete confidence in automated deploys.
 Anotherreason is simply that the cadence of business development doesn't
alwaysthematchcadenceoftechnical development.Therefore,itisnecessary to
enable human intervention in the release process.
 A facecut is used in the followingfigure to symbolize human interaction—in this
case, by a dedicated release manager.
 Howthisisdoneinpracticevaries,butdeployment systemsusuallyhavea way
tosupport how to describe which softwareversions touse indifferent
environments.
 The integration test environments can then be set to use the latest versions that
havebeen deployed to the binary artifact repository.
 The staging and production servers have particular versions that have been tested
by the quality assurance team.

Scrum,Kanban,andthedelivery pipeline
 HowdoestheContinuousDeliverypipelinethatwehavedescribedinthischapter
support Agile processes such as Scrum and Kanban?

 Scrumfocusesonsprintcycles,whichcanoccurbiweeklyormonthly.Kanban can
besaid to focus more on shorter cycles, which can occur daily.
 ThephilosophicaldifferencesbetweenScrumandKanbanareabitdeeper,
althoughnotmutuallyexclusive.ManyorganizationsusebothKanbanand
Scrum together.
 Fromasoftware-deploymentviewpoint,bothScrumandKanbanaresimilar.
Bothrequire frequent hassle-free deployments.
 From a DevOps perspective, a change starts propagating through the
Continuous Delivery pipeline toward test systemsand beyond when it is
deemedreadyenoughtostartthatjourney.Thismightbe judgedonsubjective
measurements or objective ones, such as "all unit tests are green."
 Ourpipelinecanmanageboththefollowingtypesofscenarios:

• Thebuildserversupportsthegenerationoftheobjectivecodequalitymetrics
thatweneedinordertomakedecisions.Thesedecisionscaneitherbemade
automatically or be the basis for manual decisions.
• Thedeploymentpipelinecanalsobedirectedmanually.Thiscanbehandled
withanissuemanagement system, viaconfigurationcodecommits,orboth.

Wrappingup–acompleteexample
Sofar,wehavecoveredalotofinformationatacursorylevel.

Tomakeitmoreclear,let'shavealookatwhathappenstoaconcretechangeasit propagates
through the systems, using an example:
• Thedevelopmentteamhasbeengiventheresponsibilitytodevelopachange to
the organization's system. The change revolves around adding new roles to
the authentication system. This seemingly simple task is hard in reality
because many different systems will be affected by the change.
• Tomakelifeeasier,itisdecidedthatthechangewillbebrokendowninto several
smaller changes, which will be tested independently and mostly
automatically by automated regression tests.
• Thefirstchange,the additionofanew roletotheauthenticationsystem, is
developed locally on developer machines and given best-effort local
testing.Toreallyknowifitworks,thedeveloperneedsaccesstosystems not
available in his or her local environment; in this case, an LDAP
servercontaining user information and roles.
• If test-driven development is used, a failing test is written even before any
actualcodeiswritten.Afterthefailingtestiswritten,newcodethatmakesthe test
pass is written.
• Thedeveloperchecksinthechangetotheorganization'srevisioncontrol
system, a Git repository.
• Thebuildserverpicksupthechangeandinitiatesthebuildprocess.After
unittesting,the changeis deemed fitenough to bedeployedtothebinary
repository, which is a Nexus installation.
• The configuration management system, Puppet, notices that there is a new
version of the authentication component available. The integration test serveris
described as requiring the latest version to be installed, so Puppet goes
 aheadandinstallsthenewcomponent.
• The installation of the new component now triggers
automated regression
tests.Whenthesehavebeenfinishedsuccessfully,manualtestsbyt
hequality assurance team commence.
• Thequalityassuranceteamgivesthechangeitssealofappr
oval.The
changemovesontothestagingserver,wherefinalaccepta
ncetesting commences.
• Aftertheacceptancetestphaseiscompleted,thestagingserveris
swapped
intoproduction,andtheproductionserverbecomesthenewstagi
ngserver. This last step is managed by the organization's
load-balancing server.
Theprocessisthenrepeatedasneeded.Asyoucansee,thereisalotgoingon!

Identifyingbottlenecks
 Asis apparent from the previous example, there is alot going on
for any change that propagates through the pipeline from
development to production. It is important forthis process to be
efficient.
 Aswith allAgile work, keep track ofwhat you are
doing, and try to identifyproblem areas.
 When everything is working as it should, a commit to the code
repository shouldresult in the change being deployed to
integration test servers within a 15-minutetime span.
Whenthingsarenotworkingwell,adeploycantakedaysofunexpectedhassles.
Here are some possible causes:
 Databaseschemachanges.
 Testdatadoesn'tmatchexpectations.
 Deploysarepersondependent,andthepersonwasn'tavailable.

 Thereisunnecessaryredtapeassociatedwithpropagatingchanges.
 Yourchangesaren'tsmallandthereforerequirealotofworktodeploy
safely.Thismightbebecauseyourarchitectureisbasicallyamonolith.