1

DevOps

Continuous IntegrationContinuous Delivery

Let’s talk

Presentation by: Dharmavirsinh Jhala http://blogs.digits.com

2

What is NOT DevOps?

None of the above is DevOps

http://blogs.digits.com

http://blogs.digits.com 3

What is NOT DevOps?• Is it simply taking few people from Development and few from

Operations and sit them together as a TEAM..? NO• Is it creating a new department named “DevOps” and having one or

more gentleman working with mixed skills (of both programmer and sys/network admin)..? NO

• Is it a set of tools or software suite which makes product delivery faster..? NO

• Some people may make the following claim: “DevOps is a catalog of recipes: implement them all, and you are done.” This statement is false because you will focus on finding the best solution for your individual situation by implementing DevOps. There is no one-size-fits-all solution, and no “DevOps-by-the-book” approach will solve all of your problems.

http://blogs.digits.com 4

What is DevOps?Then what is DevOps???

We can define it in one line as…

DevOps is a culture which needs to be practiced in order to do achieve organizational goals in a better and quicker way.

But DevOps is too young to define it in a single definition.

“We can also define it as a practice or culture - which makes it possible to release product often and make sure it is available to the customer with highest up-time and lowest response time.”

…and to make it possible do whatever it takes to and the catalyst which are needed to make it happen are people who plays role of DevOps.

But still there is no right or wrong approach to DevOps, there is no one hat fits all solution to DevOps and whatever makes your organization more efficient can be right for you.!

See http://radar.oreilly.com/2012/06/what-is-devops.html to know more.

http://blogs.digits.com 5

Why DevOps?• What is goal of a development team?

(business analysts, programmers and QAs)– Goal of Development is to build features and fix tickets faster

• What is the goal of an operations team?(sys admins, network admins and any other operations)– Make product available to end-user and maintain SLAs

Let’s take a look at Agile environment and how it becomes Development vs Operations because of their competing goals.!

http://blogs.digits.com 6

Agile EnvironmentDevelopment and Operations in a typical Agile Product team;

http://blogs.digits.com 7

Agile EnvironmentIn Agile project settings, roles, and responsibilities change. Roles are blurred, and each team member wears different hats. Programmers are paid to perform tasks other than writing code, and testers do more than test. Testers also help programmers to create better code.As a result, we have a changed approach, as shown by the following:• Quality: Testers are not solely responsible for quality; rather, the whole team

works together to maintain quality.• Development: Programmers do not code alone; rather, everyone helps them to

understand what to code.• Project roles: Cross-functional teams are set up and roles are decoupled from

activities.If you define work as activities to be accomplished together, you break down role boundaries and allow team members to add value in multiple areas. For example, you can enable programmers to conduct exploratory tests. Similarly, you can allow QA leads to work with the application code if they find a fixable bug.

http://blogs.digits.com 8

Dev v/s OpsIn contrast to the developers, the operations team is tasked with taking the deliverables received from the development team and making the software available on production machines such that the software can be used by the users. At the same time, the operations team often receives nonfunctional requirements (such as target values for the availability of the application). The shipped software (delivered by development team) may conflict with these nonfunctional requirements.

Operations is responsible for the availability of the software in production, and its success is often measured with metrics that calculate server uptimes, software availabilities, security, capacity (including scalability, longevity, throughput and load), and response times. These metrics are commonly defined as quality requirements (typically non-functionally requirements) that are signed as service level agreements (SLAs). They express the users’ expectations that all of the software’s features will be fully available.

9

Dev v/s Ops (cont.)The main task of the development team is to fulfill the customer’s requirements, test the solution, and provide software updates in quick succession. New features that have been implemented and tested by the developers add potential value for the customer. On the one hand, the development team wants change. On the other hand, the operations team is mainly interested in reliable and stable software. Every change forwarded by the development team can endanger the existing reliability and stability.

http://blogs.digits.com

http://blogs.digits.com 10

Dev v/s Ops (cont.)

Let’s summarize the key findings. Agile primarily improves on the classic approach by introducing the whole team approach, where developers, testers, and QA form a team that closely collaborates with the business. The unified team works as a unit of specialists who simultaneously perform general duties and who share responsibility for producing high-quality software. However, operations is not a part of that team.

http://blogs.digits.com 11

Conflicts betn Dev v/s OpsCommon scenarios include the following:1. Development passes a new release to operations, but the latter is unable to get it

running on the production system.2. The operations team contacts the members of the development team to get them to

fix the problem; the former describes the errors experienced while trying to bring the release to production.

3. In response, development blocks communication and does not offer any help.4. Development claims (correctly) that the software release ran in a test environment

without any problems. Therefore, development reasons that the operations team is at fault for not bringing the release to life. Finger pointing from both sides may end in angry phone calls, rancorous e-mails, and even escalation meetings.

5. After escalating the issue to the boss and his or her boss, two engineers are again assigned to look into the malfunction.

6. By investigating both the testing and production environments together, they discover that the two environments are different in some minor detail, such as a technical user or a clustering mode. Neither party knew about this difference.

http://blogs.digits.com 12

Conflicts (cont.)The blame game also often emerges when a new release goes live. Here is one scenario:1. Many more users are using the new features than the company expected.2. Response times slow down until the software stops responding entirely. The

users are panicking because this is the worst-case scenario.3. Escalating the issue leads to finger pointing: development claims it is the fault

of the database group, the database team blames the network group, and others speculate that the server group is responsible for the outage.

4. After going through intensive emotional torture, the company begins an objective examination that finds the root cause of the issue. However, by this point, the users have already been scared away from the new application. As a result, the company incurs heavy losses in sales and reputation.

http://blogs.digits.com 13

Conflicts (cont.)The blame game can also occur in the following scenario:1. A performance issue suddenly happens in the production system.2. Following a blame game, the developers identify an issue in the application. They work long days

before finally providing a patch that fixes the issue.3. Nonetheless, the operations team is still annoyed by the performance issue and is reminded of

similar instances in the past, where every subsequent patch further reduced the stability of the software. As a result, the operations team is leery of applying the patch.

4. The team members suggest coding the software themselves because of those problems. This suggestion, in turn, heightens the emotional tension between the teams. The operations team wants the patch to be applied in a test environment to ensure that it does not infect the overall stability of the application and that it actually fixes the performance bottleneck.

5. Unfortunately, the test environment does not fully mirror the production environment, and there are no test scenarios or test data that can imitate the exact same problem on the test machine. Days and weeks go by, and the patch is still not applied to production. All those long days spent working on the solution were for naught.

6. The management and business units increase the pressure to solve the problem, the development and operations teams continue their conflict, all are frustrated, and the performance issue on the production machine is not solved.

http://blogs.digits.com 14

Operations as BottleneckThe advantages of Agile processes, including Scrum and Kanban, are often nullified because of the obstacles to collaboration, processes, and tools that are built up in front of operations. As a result, software is released frequently but only in test environments. Consequently, software is rarely brought to the production phase, which transforms a new release into a solution and provides value to the end user and to the customer. In other words, not all releases are produced, and deployment to production often happens after the development team has coded and tested the release. In sum, the cycle time (i.e., the time from the inception of an idea to its delivery to users) is still too long.

http://blogs.digits.com 15

Challenge

• A recent survey shows that only 17% of IT executives feel that they deliver fast enough for the pace of the business.

• A high proportion of incidents are result of human errors in the manual release of software.

• Development and Operations have different goals, values and ways of working that are often not in alignment.

http://blogs.digits.com 16

DevOps to RescueIn the past few years, many people have worked to apply Agile approaches to operations. Those approaches aimed to eliminate the wall between development and operations and to address the structural conflict between those two departments. By sharing experiences and possible solutions, the movement formed into what is now called DevOps. The processes by which the movement formed itself and discussed and provided solutions to the pain points summarized above are similar to how the Agile movement started its work years ago. From another perspective, DevOps aims to extend Agile to operations.

With the DevOps approach, the developer role consists of programmers, testers, QA, and experts from operations. They all develop software and help to bring it to the user. (culture)

DevOps uses automation techniques to increase collaboration across development and operations, enabling faster, more predictable and more frequent deployments to market. (automation + processes)

http://blogs.digits.com 17

DevOps to Rescue (cont.)

http://blogs.digits.com 18

DevOps to Rescue (cont.)Challenges How DevOps helps?

Inefficient practices Streamlined practices

Phased delivery Continuous delivery

Error-prone manual processes Automated quality processes

Silos between teams (Dev and Ops) Integrated teams

http://blogs.digits.com 19

How to practice?

http://blogs.digits.com 20

How to practice? (cont.)• Automate, automate, automate everything which is manual

as a first step:– Find the right tools to automate build, test and deploy and glue

them all together with scripts• Have talk between Dev and Ops:

– Make Developers aware about Operations and production environment

– Make Operations aware about Development environment, tools and application architecture

– and continuously update each other about any changes in their plate

– Production like test environments

http://blogs.digits.com 21

What to expect?

http://blogs.digits.com 22

Let’s take an example of FooBar Product

Continuous Integration (Phase 1)If we take Foobar or any cloud based SaaS product has REST APIs and GUI as it’s components then following are high level tasks which needs to be accomplished in order to achieve CI for the product:• Set up a CI server (Depending on infrastructure – it could mean new VM with pre-defined server software pre-installed or

creating new build on the same application/web server)• Have daily build which checks-out the code from the repository • Run database changes scripts automatically• Run automated tests for REST API and GUI• Mark automated-build status as Pass or Fail based on results of automated TestSuite run (best-case scenario in case of

100% coverage)– In real-life case where GUI test-cases don’t have satisfactory coverage – REST API can be maintained in separate branch in a repository and

when there is no commit in GUI branch we can consider that build Pass/Fail based on automated TestSuite run.• Every commit will have bug-tracking or requirement ID attached, automated test-case will update status of those tickets

(or respective IDs) based on run-status (associated dev+qa gets notified)• CI – at least build once a day, can give automated or semi-automated status of the build each day

* Primary benefit I see is that, it helps identify problems early (even if 100% automated test-case coverage is not achieved) and have Programmers fix issues before it goes to QA.

- keep in mind, this is just a beginning;- Phase N with DevOPS, continuous release…and so on.!

http://blogs.digits.com 23

How to measure DevOps success?

These are top 5 KPIs that make a case for DevOps:• Deployment frequency• Speed of deployment• Deployment success rate• How quickly service can be restored after a

failed deployment• Culture(https://puppetlabs.com/blog/5-kpis-that-make-the-case-for-devops)

http://blogs.digits.com 24

What is against it?

• NoOps?? – More • “If DevOps is a growth engine for your company, then

outsourcing it is like building a car with the motor located elsewhere,” says Michael Riley, Co-Founder, Boxter http://contentboxter.com. Optimizing DevOps requires tight integration between differing and complex entities. If a service can wrap this system into an external package for an enterprise, then either that customer doesn’t have a real need for DevOps or this approach is going to hurt the business, concludes Riley.(http://devops.com/2014/10/09/devops-com-examines-devops-service/)

http://blogs.digits.com 25

How to Sell CI/CD/DevOps as a Service?

As, - practice experts- experts of tools in CI, CD and DevOps space- TBD

http://blogs.digits.com 26

Similar Service Providers in Market• http://www.logicworks.net/cloud-automation/DevOps• http://www.base2services.com/devops/#• http://www.itcinfotech.com/software-product-engineering/devOps-solutions.aspx• http://clogeny.com/devops/• Accenture

http://blogs.digits.com 27

Tools & Platforms

http://blogs.digits.com 28

Making of a DevOps Engineer.!!!1. An expert sysadmin2. Virtualization expert3. Broad technical background 4. Scripting Guru5. Borderline developer (more is better)6. Chef, Puppet or other automation tools experience7. People Skills8. Customer Service 9. Real Cloud Experience 10. Someone who careshttp://www.vminstall.com/devops-skills/

http://blogs.digits.com 29

Q/AFor the audience:

• What are your expectations from this role?

http://blogs.digits.com 30

ResourcesFollowing resources were used as references in order to understand the subject and compile this presentation:Articles• https://www.thoughtworks.com/continuous-integration• http://radar.oreilly.com/2012/06/what-is-devops.html• http://radar.oreilly.com/2015/02/what-is-devops-yet-again.html• http://perfcap.blogspot.com/2012/03/ops-devops-and-noops-at-netflix.html• http://radar.oreilly.com/2015/01/devops-keeps-it-cool-with-ice.html• http://devops.com/2014/10/09/devops-com-examines-devops-service/• https://www.jeffknupp.com/blog/2014/04/15/how-devops-is-killing-the-deve

loper/

Books• http://www.amazon.com/DevOps-Developers-Experts-Voice-Development/d

p/1430245697

31

Thank You!

Dharmavirsinh Jhaladharmavir@digitss.com