5 Best Practices for Implementing

DevOps

Successful Outsourcing

6 DevOps Myths• DevOps is not New or

Mysterious• Formal implementations

have been around for more than 5 years• Before formal

implementations appeared, many early adopters were using agile as a guide to the integration of development and IT operations

6 DevOps Myths• Some common myths that surround DevOps1. The best information about DevOPs was written

yesterday (Nope)• First described in conference in Belgium in 2009. • A lot of information from practitioners in the field has been

made available on the web• There is good information being developed currently too but

– DevOps is not (primarily) a technical subject. Current ideas from conferences, tool providers, etc. may be great but – if they don’t have wide acceptance and validation – you might want to let the fog clear…

6 DevOps Myths2. DevOps is a Skill (Not really)• Your neighbor/friend/etc.

has a DevOps implementation. It is not setup the way yours is but – both can be very successful in their own environment

• You can’t hire your way into a great DevOps team simply by searching resumes.

• Great DevOps teams are developed culturally, in the same way agile methodology is integrated into development practices.

• Teams are built out a common desire to improve & integrate development & IT operations practices, processes and systems. It doesn’t (and can’t) happen overnight.

• One person can help lead an effort from past experience, but without full, active participation from all team members – the results will be eyewash at best.

I’m a DevOps Guy! See it on my resume?

6 DevOps Myths3. DevOps is all about

automation (Every tool vendor will tell you this but…)• There are many good tools for

automating tasks and systems as a part of DevOps, but no branded tool is essential

• Many of the best-known and widely-used tools are open source and scripts that have been around for many years.

• Automation is part of DevOps – but not the point of an implementation

6 DevOps Myths4. If you are going to implement DevOps, throw out

everything you know and start over. (Actually, the opposite is true)• Most successful implementations start from practices and

processes teams are already using, scaled out to organizational level and consistently improved with best practices

• Big bangs – where everything is restarted from scratch – are bound to cause great disruption and distraction.

• Start small, build on what works, continue to examine and improve• Don’t kill the messenger or refuse new ideas outright. Welcome

new ideas, but don’t let anyone tell you everything you are doing is wrong and can’t be build upon.

6 DevOps Myths5. If you are going to implement DevOps, you need to

be ready to virtualize everything. (A virtual non-starter for planning)• DevOps implementations often start from a need to better

manage or take advantage of tools for virtualized infrastructure• But if you are not (currently) virtualized, that shouldn’t stop

you from implementing DevOps. And if you have no need to head in that direction – it isn’t a show stopper.• The culture, the tools, practices around DevOps – applies to

all types of environments: physical, virtual and mixed. • Virtualization, simply for the sake of using the technology

and nothing more, creates an extra layer of confusion and practices to work through.

6 DevOps Myths6. We don’t need DevOps – We’re not in the technology business!

(Maybe you don’t know what drives your business…)• Almost all businesses today use software to run their core business

processes. • In today’s business, nothing stands still. Only change is constant. • Organizations that cannot evolve, that are based on software that is

stuck in version one, put their future at risk. • DevOps, like agile, is a methodology based on helping teams work

together towards common goals through iterative operations• Collaboration, communication, & repetitive operational improvement

are requirements for all organizations that want to leverage lean, agile, and DevOps methodologies

• There are more but – you get the idea…

5 Best Practices for Implementing DevOps

1. All hands on deck!• Just as agile emphasizes direct

communication & collaboration between developers and product owners, DevOps emphasizes the same between all stakeholders involved in software development, deployment and operations.

• DevOps implementations are not built among a limited number of key engineers in rooms lit by LCD monitors

• Implementations are team efforts that succeed or fail based on active, committed participation of everyone and their own, initially self-centered, needs.

5 Best Practices for Implementing DevOps

2. Leave ad-hoc, one-off processes and systems for repeatable manageable practices• You won’t spend time improving a process or system you’re

not planning to reuse or repeat.• You can gain from focusing on common practices (industry

standards), integrating them into a process flow that crosses silos from development, through deployment, to operations. • Formalizing processes and practices provides an understandable,

repeatable process across an organization that can be managed and examined for opportunities incrementally. But what practices should you concentrate on?

2. Implement Repeatable, Manageable Processes • Test Automation• Test-Driven Development (TDD) is not a new idea – it is

common practice in agile development teams• From a DevOps point of view, it promotes early testing, run

by the developer several times a day. Promotes early testing and gives developers the responsibility to correct problems during development rather than later in the process.• Lowers risk in release process and issues caused when an

app going into release hits show-stopping faults

2. Implement Repeatable, Manageable Processes • Continuous Integration• Another result of agile development practices• Builds on test automation by leveraging version control and automated

regression testing• Assures new code is tested in the context of the existing functionality

of the application itself • Provides a method of roll back to revert to an earlier, working version

of tested code when necessary• Developer-level, automated testing focuses on newly developed

functionality before it is committed to the app. Continuous integration focuses on quality at the application level as the new code is added.

• From a DevOps perspective, it is another step in a chain that assures quality and sets the stage for continuous deployment

2. Implement Repeatable, Manageable Processes • Integrated configuration & change management• In operational practice – these two processes are joined at the hip• Integrated configuration management in DevOps brings the dev team

into the wider sphere of operations• (Example) Instead of building new web services – the team needs to ask, “what do

we need to do or change to use an existing service instead of re-inventing wheels?”

• (Example) If a change is needed to an existing service – change management brings operations into the picture so they can provide developers other systems that would be impacted by change, what consequences or opportunities a change could expose at the enterprise-level

• Systems-level thinking brought into development is sometimes avoided because it seems to open a “can of worms” as it exposes dependencies and brings stakeholders into the discussion – but that is exactly what DevOps is supposed to do…

2. Implement Repeatable, Manageable Processes • Integrated Deployment Planning

• In agile, the incremental deployment of applications is a natural outgrowth of incremental development, automated testing, and continuous integration but…

• Operational constraints and silos often limit or stop incremental deployment in favor of pre-planned release periods

• Leveraging the inclusion of stakeholders in development, operations, and support in the deployment process opens the opportunity for planning to start at the beginning of development and allows end-user involvement at a much earlier point. • Avoids building a bug-free app – that doesn’t meet user needs and

expectations• Organizational integration problems are detected before the application is

rolled into daily opportations.

2. Implement Repeatable, Manageable Processes • Continuous Deployment

• With all of the foregoing processes in place, DevOps sets the stage for one of the most important outcomes of implementation – the capability to release new features to existing applications as they are developed

• Opens the organization to a virtuous cycle of user-driven improvement and a true “agile enterprise” approach

• Brings everything that lean and agile methodologies offer to software driven systems

• Cannot happen without all the other points mentioned – is not a stand-alone process

2. Implement Repeatable, Manageable Processes • Application monitoring & automated dashboards

• In some ways – these two features of DevOps implementations have been looked at as “icing on the cake.”

• Application monitoring requires that the development team build in or provide integrated tools for apps that assures that they will scale properly, utilize resources as expected, and not become jammed when associated systems don’t respond as expected.

• Automated dashboards provide enterprise oversight to assure that processes across many builds and deployments are operating reliably and consistently. Dashboards provide feedback on systems at a macro level providing opportunities for general improvement in DevOps implementations

• Not all DevOps implementations include these aspects, especially in small or single product focused implementations, but they are becoming critical as maturity rises

3. Automate Building Environments• When proven and successful practices

are in place, leaving the building of environments to manual setups by a spare IT person or developer raises the risk that necessary elements or requirements will be left out – or gradually reversed to legacy standards

• In situations where virtualized infrastructure is used, the many options available can make this a critical step, but one that is very open to scripting and other simple automated approaches

• Halting development to reconfigure what should have been a standard environment as a project is ramping up to production can kill team productivity

4. Approach DevOps as a Cultural Change• To be successful, DevOps teams must want to leave their

silos and work as one collaborative unit. • The end goal must be to bring organizational capabilities to

the point where a virtuous, iterative cycle of improvement can become routine. • There will be temptations to switch to a “big bang, do it all

now” or “just adopt these tools and be done with it” implementation. These are roads to failure. • Like any cultural change, it requires open input from all

stakeholders. It isn’t just tools. It isn’t just people and roles. It requires real, lasting change.

5. Don’t Succumb• Don’t fall into the trap of setting up new DevOps titles and roles

that simply build new silos and fiefdoms• Once the implementation is showing positive results, there will be a push

to protect your advances with titles like “Automation Architect,” ”DevOps Security Engineer,” etc.

• People who have spent the time to think deeply about an area can become natural centers for practices but…• Once an area becomes their domain, it is no longer everyone’s concern• Instead of everyone being involved and responsibile, the team looks to the

”responsible person.” Their answers or lack of interest in a problem can become the questionable end of the discussion.

• It is a conumdrum, but the same as agile in this respect. More positions and titles just assure that individuals don’t have to take responsibility and participate in solutions fully. There is a slippery slope in setting up DevOps titles and roles.

Is That All? • There are many more best practices that could be

important in specific implementations• Chances are that that if you work towards your

implementation incrementally you will find them – as they apply to your organization. You don’t need to go for everything at the beginning. • Work on each area, gain success and acceptance.

Build on success and move forward. • Throw the grand DevOps implementation plan in the

trash, or if you are cornered into having one, keep it high level, goal rather than time dependent and let your team fill in the blanks.

Did We Mention Outsourcing? • You

can bring outsourced teams into the mix• There are vendors who are

experienced with DevOps implementations, who can play an active, partner-level role

• If you see your organization as one of those that fits the “we’re not a technology company” statement – an outsourced partner can be a real asset allowing you to bring benefits that you don’t have resources to cover internally

Did We Mention Outsourcing? • We’re Scio

• Nearshore, outsourced, software development and DevOps services provider for our customers in North America.

• Experience with dedicated teams in DevOps environments, developing DevOps solutions for customers that need to work with continu0us release deployments and agile teams.

• We can work at a partner-level for long term, sustained improvement

• If you would like to know more – Contact Us.