Introduction To DevOps - CC Pace PDF Free Download

1y ago

22 Views

1 Downloads

1.55 MB

34 Pages

Report/dmca

Download PDF

Transcription

IntroductionsCC Pace is one of the nation’s mosttrusted Agile technology companies,having pioneered and perfected Agilesoftware development, coaching, andtraining since the movement’s earliestbeginningsOur trainers are practitioners with apenchant for training – deliveringuncommon knowledge with theflexibility and interactivity thatpromotes real learningSlide 2Copyright 2017

About me 20 years developing, deploying, and supportingproduction software 10 years of Agile development experience, includingScrum, XP Often act as both Dev and Ops in an organization or on aproject Consultant on many engagements and projects for largeand small organizations – from startup to wellestablished.Slide 3Copyright 2017

Consider this How long would it take to deploy a change involving a single line of code? How many groups and resources would be involved? How confident would you be in the outcome?Slide 4Copyright 2017

Why DevOps?DevOps is a software development method that stresses communication, collaboration, integration,automation, and measurement of cooperation between software developers and other informationtechnology (IT) professionals. -- WikipediaComplementary methodologies include Scrum, Extreme Programming (XP), and Kanban.Reasons to adopt this method: Reduce time to deliver featuresReduce time to testMinimize deployment issues/downtimeMinimize post-deployment operational issuesIncrease confidence and reduce stress during deploymentSlide 5Copyright 2017

What are some of the common problems that organizations face?1.Long cycle time or lead time Delay in getting value to end user Agile Development often makes this transparent2.Mistakes during deployment Manual processes, Hero mentality Deployment seems completely new each time3.Large overhead in deployment process Complex change control, heavy documentation (Readiness reviews, etc.) Often causes rushing to get things done at the end4.Customer impact from deployment Downtime Infrequency of deployment means huge feature setsSlide 6Copyright 2017

A “wall of confusion” between Dev and OpsLeads to resistance from operations staff Mainly due to inconsistentdeployments and customer impact Blindsided by development teamswww.dev2ops.orgSlide 7Copyright 2017

How do we start?Cultural“Even with the best tools, DevOps is just another buzzword if you don’thave the right culture”- Rouan Wilsenach (Martinfowler.com) Everyone is responsible for qualityIntegrated teamsCross-functional teams; Ops involved earlyCo-locationRemove fear of failureResponsibilities expandedDevelopers support their own code during on-call rotationsAvoid manual sign-offs if possibleSlide 10Copyright 2017

Team ProfileWhat’s the profile of someone that thrives in a DevOpsenvironment? Interested in automation tools, but knows when humanintervention is more productiveDeveloper that has worked with Ops before totroubleshoot and fix production issuesOperations engineer that has consulted with developerson architecture decisions (security, performance,scalability)Prefers shorter feedback cycles/iterationsAvoids blame mentalityObsessed with verifying their own workSlide 11Copyright 2017

How do we start?Technical:Foundational Version Control SystemAutomated TestingAutomated Build toolsContinuous IntegrationAdvancedHolistic Deployment orchestration Logging and MonitoringVirtualizationInfrastructure as CodeConfiguration ManagementSlide 12Copyright 2017

Foundations: Version Control System Modern VCS (SVN, Git, Mercurial, TFS) Practices‒ Version control everything that is necessary to delivervalueo Code, Configurations, Documentation, Schemas,Firewall rules‒Check-in often, Check-out often, Merge frequently‒Use clear commit messageso What, Why‒Work from a single trunko Feature Toggleso Feature branching is an optionSlide 13Copyright 2017

Foundations: Automated TestingManual testing is slow. Manual regression testing is slower and error prone.Instead of writing test plans, write tests! Automate all testing required for deployment.LevelTypeExample Tools for automationCommitUnitxUnit (JUnit, etc.), Mockito, DBUnit, TestNGAcceptanceFunctionalCucumber, Gauge, Rspec, Selenium, Fitnesse, JBehaveIntegrationxUnit, SoapUIPerformanceJmeter, DBUnit, LoadUISecurityOWASP coverage via Unit and Functional tools, Scanskicked-off via scriptsSection 508SeleniumSlide 14Copyright 2017

Foundations: Build Tools Eliminate all manual processes for compiling, deploying, and testing software No longer relying on an IDE to do this Allow developers to run full builds locally Run all your automated tests via the build tool Version control all build files Don’t version control binaries. Consider putting them into a repository (Nexus, Artifactory,NuGet) Example tools: Gradle, Ant, Maven, Rake, MSBuild, BuildrSlide 16Copyright 2017

Foundations: Continuous IntegrationPractices: Run build on each commit Run tests locally before committing to VCS Setup notification (access to CI server GUI is usually easiest) Don’t check-in on broken build Never go home when the build is broken Time box fixing the build. Revert if time is up Can do more checks of code quality than just unit tests (eg. SonarQube, Checkstyle, FindBugs)Slide 18Copyright 2017

Holistic: Deployment Orchestration Binaries built once at commit stage and deployed in other stages includingproduction Deploy with same scripts/process in each stage Smoke test deployments Staging phase similar to production Any failure stops the deploymentSlide 21Copyright 2017

Advanced Practice: Logging and Monitoring Transparency into production for whole team Immediate problem notification Historical data also provides insights Use of dashboards Constantly monitor all aspects with testsExample Tools: Nagios, New Relic, Splunk, Cucumber-NagiosSlide 23Copyright 2017

Advanced Practice: VirtualizationInfrastructure Provisioning:1.2.Automated rather than manualUse virtualization Provisioning and configuration as part of an automated build Eliminates the “works of art” risk Not just server VMs! Platform as a service, too.Example Tools: Puppet, Chef, Ansible, VMWareExample Cloud Providers: AWS, Rackspace, Heroku, GoogleSlide 25Copyright 2017

Advanced Practice: Infrastructure as Code Server configuration is managed through code Visibility for both developers and operations via Version Control Some tools offer visual designers that export to code Controlled, predictable, repeatableSlide 26Copyright 2017

Advanced Practice: Configuration Management Limit configuration via GUI Nothing hard coded in application Same configuration processes used in every environment Essential for automatic provisioning All configurations are version controlled Security related configuration items (passwords, encryption keys) usually stored in a differentrepository than code.Slide 27Copyright 2017

Takeaway – Low tech tipsProblemWhat can help?Ops diagnoses an issue in anenvironment – doesn’t tell anyoneTreat urgent issues as mini-projectsApplication feedback Not enough information Low-value information Alert over-load Treat Ops as another customer Log review sessionsSlide 29Copyright 2017

Takeaway – Low tech tipsProblemWhat can help?Adding risk to a deployment by addingmore and more stuff becausedeployments are expensive. Deploy more often, rather thanrelying on big-bang deployments Automation and repetition courage Finger pointing rather than problemsolving when problems occur. Empathy – Dev’s sit-in on adeployment Lack of effort to make things easierfor other groups.Slide 30Copyright 2017

Final TakeawayHow would you assess your organization? How much testing do the developers perform? How often do developers integrate their code? Do they wait until a feature iscomplete? Do your developers know the Mean Time Between Failure (MTBF) of the applicationin production?Slide 31Copyright 2017

Final Takeaway Does Ops have to manually configure apps before deploying them to an environment? What if you need a new test environment? Can you easily tell what version of your app is installed in an environment?Slide 32Copyright 2017

Summary/Wrap UpResources Continuous Delivery by Jez Humble and David Farley Continuous Delivery and DevOps: A Quickstart Guide by Paul Swartout The Phoenix Project by Gene Kim, Kevin Behr, and George Spafford Lean Startup by Eric RiesSlide 34Copyright 2017

Foundations: Continuous Integration Practices: Run build on each commit Run tests locally before committing to VCS Setup notification (access to CI server GUI is usually easiest) Don't check-in on broken build Never go home when the build is broken Time box fixing the build. Revert if time is up