devopsy.kinsta.cloud

Author: contributor

What the Auto Industry Can Teach IT Development

The latest and greatest advances in technology often draw the spotlight, but the truly great changes in business aren’t driven by technology alone. They’re enabled by a change in culture that’s supported and accelerated by technology.

Consider the assembly line in the auto industry. Automation, specialized tooling and robotics have provided a boost to quality and efficiency, but these advances only mattered because of a change in U.S. culture that emphasized speed, acceleration and economies of scale. Henry Ford capitalized on these cultural constructs to implement an innovative set of tools that revolutionized auto production. Toyota led the next evolution in auto manufacturing with its implementation of the Andon cord and Kaizen continuous improvement (CI) but similarly, these tools depend on a culture of trust and respect for the workers to be useful.

In the field of software development, a similar shift is taking place through the DevOps movement that’s leading to faster, more efficient and higher quality application development. Technology has made DevOps easier to implement, but these new tools only add value when they are accompanied or even implemented via a change in culture across the entire organization and all technology areas. This includes items such as visualizing the delivery value stream to identify areas for improvement, increased trust and collaboration across silos and a CI mindset.

A key aspect of DevOps is automation, and automation is only possible when patterns can be created, which requires eliminating any variances in practices and capabilities in all aspects of the organizations that don’t add value. For example, if every application is a snowflake in terms of its architecture and configuration, infrastructure automation won’t be possible. If release planning, management and deployment don’t have standard work associated with them, then again, an integrated delivery pipeline capability cannot be implemented.

Nationwide’s Journey to DevOps

At Nationwide, we began a change in how we developed applications almost a decade ago. At the time, the term was “agile.” We shifted application development to focus on smaller iterations of work with automated build and testing practices. While this proved valuable, we realized this was only part of the journey of accelerating our lead time from customer concept through delivery of business value.

We started the journey to implement a Lean-based DevOps model that encompasses the entire development value stream, from the incoming business request to application deployment and monitoring. Our goal was to work more closely with the business units to continuously plan, design, develop, test and deploy incremental improvements in our application-based products.

Nationwide has seen demonstrable benefits on this journey. Critical defects have declined by 80 percent, system availability is up 70 percent and on-time delivery of applications has risen to 90 percent from 60 percent. More importantly, we’re starting to see results in our business as we refine our ability to test business hypotheses and measure the results in terms of increased revenues.

Infrastructure to Support the Cultural Shift

Just as Ford’s auto assembly line utilized advanced technology to be successful (e.g. electricity enabled optimal placement of machines versus steam power), accelerated delivery is utilizing the development of new technologies. To advance DevOps, we use IBM Rational and UrbanCode software to manage and deploy applications. The new technology, though, has only worked because we have committed to both a technology and cultural change across our entire organization. We have more than 5,000 IT professionals on 200 different teams. Every team—whether it’s responsible for the mainframe, distributed, web or mobile— needs to utilize the same standard work approach to application development.

Let me give you one example of how that works: Biweekly show-and-tells are a core part of our approach. For new mobile applications, the changes after two weeks might be dramatic, but even for the larger applications running on our IBM z Systems mainframes, the teams have something to share. They break the mainframe application work into smaller units and demonstrate updates they’ve made that fit into more long-term initiatives.

The Autobahn for Application Development

While applications and products are not all developed at the same speed (e.g. a change to a mobile app versus a regulated change to back-end banking system), there is a need for these systems to utilize similar approaches and a common delivery pipeline with visibility of dependent changes, to be implemented as quickly as possible.

An example of this is a highway like the Autobahn accommodating different types of drivers and vehicles, such as a Porsche built for speed and a semi-truck built to carry cargo. The rules of the highway allow vehicles to drive at different speeds safely without having stoplights by providing exit and entrance ramps, speed limit minimums and visibility of other vehicles along with “standard rules of the road.”

Likewise, we want our IT delivery capability to accommodate variable speeds of IT based on the business needs and the development teams’ abilities to go faster by implementing practices such as smaller batch sizes, APIs and microservices, feature flags and performing automated testing and readiness validation. While distributed and mobile applications might be the Porsches on the road, they can only go as fast as the mainframe and legacy applications, or semi-trucks and other traffic will allow.

Consequences of Resisting Change

No company will get through the next decade without being disrupted, either externally or internally via a continuous improvement and innovation mindset. Those that embrace Lean and DevOps practices across the entire IT organization will have a steady stream of new services and improvements that outpaces the competition and transforms their business. Those who don’t will join former Fortune 500 companies that waited too long to realize that their competitor’s Porsches and semi-trucks were too far along to catch up with.

About the Authors / Carmen DeArdo and Jason Patterson

Carmen DeArdo is the director of Build Technologies at Nationwide Insurance. He is responsible for helping drive accelerated delivery utilizing Lean and DevOps techniques across the end-to-end delivery value stream. One current focus area is the creation of an integrated delivery pipeline capability.

Jason Patterson is a Lean and Agile coach at Nationwide Insurance. He works with development and support teams across the company to help recognize process gaps and opportunities in their delivery stream. His background in development fuels that energy, while he resists the urge to automate every broken or unnecessary process. After nearly a decade at Nationwide and seven years experimenting with extreme programming, scrum and agile methods in a software development department at Indiana University, Jason is still learning.

August 17, 2016
What DevOps Skills are Organizations Looking for?
DevOps is a cultural, philosophical and organic approach toward automating workflow and getting products to market more efficiently and effectively.

DevOps engineers are in top demand right now. According to studies by Gartner, 25 percent of top global 2000 organizations will have adopted DevOps as a mainstream strategy by the end of 2016.

DevOps is both a cultural movement and a philosophy … which can make it difficult to define the specific skill set you need a DevOps team to possess in order to function successfully.

Of course, an excellent way to show fluency in DevOps is by earning a DevOps Institute certificate—for example, DevOps Foundation^®.

That being said, there are some “mission-critical” DevOps skills that organizations are searching for pretty universally right now.

1. Experience with infrastructure automation tools and fluency in web languages

Experience with tools such as Ansible, SaltStack, Puppet, Docker, Chef and Windows PowerShell DSC as well as fluency in languages including Ruby, Python, Java and PHP are must-have skills for DevOps pros.

Organizations are searching for DevOps candidates who are highly proficient in many of these tools and languages and open to increasing their competencies further when given the opportunity to do so.

2. Expertise in “soft skills”

DevOps evolved as a way to enhance collaboration across project life cycles and connect front-end and back-end professionals on either side of the software development and operations spectrum.

When software developers and operations staff (system engineers, systems admins, DBAs, etc.) collaborate effectively, communicate honestly and work as a cohesive team, the software development life cycle (SDLC) is streamlined, risk factors are mitigated, and projects are completed and deployed with a minimum of bugs, quality defects and glitches.

In addition, it can be useful for organizations to have DevOps specialists on their team who are comfortable in the role of client consultant, able to interact effectively and build positive business relationships with customers while addressing their needs and wants.

Organizations look for DevOps candidates who are skilled in interpersonal communication, with an arsenal of listening, negotiation, problem-solving and team-building skills at the ready.

3. Familiarity with CI (continuous integration) tools

Continuous integration is a DevOps methodology that continually merges source code updates from all developers on a specific software build, notifying the team of any failures in the process.

This offers a real-time window into the developing software system, allowing immediate and constant engagement of all team members throughout the project lifecycle.

CI tools DevOps candidates should be familiar with include CruiseControl, CruiseControl.NET, Jenkins, Bamboo, Hudson, ThoughtWorks’ Go, Urbancode’s Anthill Pro, Microsoft’s Team Foundation Server and Jetbrains’ Team City.

4. Bonus Skills

Other skills hiring managers are on the lookout for in the DevOps space include:
- Extensive knowledge of software build cycles
- Experience deploying code
- Experience in software architecture
- Familiarity with application programming
- Database management
- System design
Useful experience and certifications include:
- Project Management
- Risk Management
- Scrum Master
The good news is that the industry’s need for DevOps team members with diverse and evolving skill sets is in sync with what DevOps candidates want from their workplace. According to the 2014 State of DevOps Report from Puppet Labs, an atmosphere conducive to learning is a primary component of job satisfaction among DevOps engineers.

About the Author / Robin Borough

Robin Borough is President of Omnikron Systems, Inc., which offers IT and management training and IT staffing services. As an advisor to technology professionals and executives for over 25 years, Robin has built a world-class reputation as a “go to” career strategist in the IT industry, one who’s capable of successfully guiding executives and specialists, at any level, through transition.
August 16, 2016
Does Modeling Have a Place in DevOps?
As organizations adopt DevOps, they not only release smaller changes sooner, but they also change the way they develop software. Additionally, applications no longer are seen as giant monoliths, but rather as dispersed across dozens of services that may be built on different platforms (from Node.JS to .NET), depending on the team and technology du jour. To complicate matters even more, as technology is changing, so are business requirements.

This is where an application model comes in. It saves time, ensures quality and increases organizational knowledge of the application and its components that are constantly being changed and rebuilt. This article will explain what an application model is, who is involved in creating one and how to start using it.

What is an Application Model

The application model is not a specific set of unified modeling language (UML) diagrams or models used in a direct 1-to-1 relationship with the code. Rather, it is a high-level document that furthers understanding of the application and helps provide insights about that application.

The model needs to be approachable to personnel from many different business roles, including developers, project managers, IT administrators and even users. The array of people who might use the model should give a rough idea about technical level.

What makes the application model so different, so useful and so important is that it defines not just the field of the application but also the specific domain, which is also why it can be called a domain model.

Field vs. Domain

For example, a core function of banks is to underwrite loans, but they do many different types of loans. A field of underwriting could be as specific as commercial underwriting for loans over $5 million. This field will have many similarities no matter the bank because underwriting is a regulated practice; therefore, the information used to make a decision is mostly identical.

However, the field isn’t specific enough to create an application model because it doesn’t include the unique factors of a specific bank—things such as the amount of weight a system gives to any number of loan factors (credit score, cash on hand, etc.), processes that are unique to an individual bank or even specific nomenclature that bank uses. All of these factors go into creating the application model.

In the end, the team gathered will build a complete model of what the application is and how it currently works. It’s important that the model being created reflects the actual application and not an idealized version of it. Because many business applications are quite large, it often makes sense to have a broad model for the entire application and several more intricate models for specific sections or features.

Bite-sized chunks

For example, a bank will have different criteria for commercial underwriting depending on size, income and even type of business. While the overall application covers all the different types of businesses being underwritten, different sections could easily be divided by requirement and modeled individually as part of the whole.

Lastly, it’s important that the model is reflected in the code base for easy understanding by the development team. If the model is meant to serve as a central hub for conversations about changing and improving the application, the decisions and insights found during those conversations can be relayed and documented for the development team more easily and much better if there is a tight relationship between the model and the code base.

How to Create the Model

As mentioned earlier, the model must be approachable and understandable to individuals across many different business roles and with different backgrounds because it is the thing around which conversations about change and improvements happen. So, the first logical step in creating the model is assembling the team.

The core team should share several attributes for success. They should all (no matter their business title) be very familiar with the application and the current processes; this is not the place to learn about how things work.

At a minimum, the team should include developers, operations and project managers, but knowledgeable users can also be invaluable. Everyone should also be above average communicators because they will be working to create understanding with the core team and relaying that understanding to non-team members.

Communication Matters

Communication is an extremely important skill for any member of the model team to have. For example, there could be an incredibly gifted developer who has vast knowledge of the application being modeled, but who speaks the local language as a second language and without advanced and nuanced proficiency. This is fine when changes that they are working on are documented through a ticket system and can be understood by reading the ticket and looking at the code base; however, it’s not appropriate for the modeling team.

At best, that developer will slow down the entire modeling process because they will have to ask many questions to fully understand what is being said by non-developers. At worst, that developer will not ask questions to get the understanding needed, and therefore will not be able to share their insights with the modeling team nor adequately explain the model to fellow developers.

Once a team has been created, the best start is to talk about the application itself as it is. The goal is to create a shared understanding of how the application works and how it’s being used. Some good starting topics are:
- What does it do well, what doesn’t it?
- What’s missing from the application?
- What’s in the app that’s not being used?
- What other applications does this interact with and which processes?
- Is the application being misused (e.g.: a field labeled one thing used for another)?
- What is the process and data flow?
- How much overlap is there between data and objects?
- How granular are security requirements?
- What are the application deployment specifics?
- Which users will need access?
- Which APIs will be used?
- What are the Performance and Health Monitoring requirements?
Conversing around a whiteboard is often helpful for quick sketches and lists that everyone can see. You’ll note that there are both non-technical and semi-technical topics above, so a good project manager who is familiar with both ends of the application can be invaluable in facilitating discussion.

Miscommunication

For example, if an underwriter who works on business loans was describing the process to a group modeling an underwriting application, they might inform the group that a credit rating is one of the factors that is used in determining loan worthiness and needs to be recorded in the application. Credit ratings are something that everyone who has ever had a credit card, home loan or even auto insurance is familiar with. However, it also presents an opportunity for miscommunication.

Individual loans (for things such as a mortgage) use a credit rating score that can go up to 850. A developer might know this from personal experience and create a field on in the application to record a credit score. Restraints on the field could be numeric only, with a range of 300 to 850 (this would help ensure that only valid scores were entered). However, businesses are given credit ratings with letters and symbols—not numbers—such as AAA, for example.

In this example, if there were no follow-up questions and no examples used even though multiple people on the team were using the same term and thought they were using it correctly, there is still miscommunication that would result in an error in the final software that would then need to be fixed.

As discussions progress (and it will take time), what is being developed by the modeling group is a shared understanding of the application, as well as shared knowledge of how to talk about it. This allows words to be used precisely with the assurance that everyone on the team is using them in the same way.

Sometimes this understanding is referred to as a universal language because through questions, miscommunications, explanations, demonstrations and discussions, what was created by the core group is a way to easily and fluently talk about the application without any misunderstanding.

Using this shared understanding documenting the application should be achievable. Because the application model isn’t a set series of diagrams or maps, there isn’t a definitive template for creating one, but many teams have found that a combination of data flow, activity, use case, sequence and component diagrams are at a high enough level that everyone can understand and use them, while still being technical enough to be useful for the development team. It can also be helpful for text documents of notes, snippets of sample code and even photos of whiteboard drawings to be part of the model.

Of course, a series of diagrams and notes can be messy to use and organize, so oftentimes a mind-map can be helpful as a method of keeping track of the disparate parts and diagrams and maintaining ease of use.

Modeling for Development

Having a model is all well and good, but how does the model help with development? By defining the application not just from the developer point of view, insights will have been gained about what needs to be tweaked, what needs a major overhaul and what needs to be demolished completely.

By not just knowing what needs to be changed but why it’s broken and what lead to the break makes changing the software not just an issue on a ticket, but a complete picture. Also, noting application traits such as data overlap, object reuse and layers of abstraction allow the core development team to be able to develop and iterate quickly without worrying about changing functionality in an unplanned way, thereby saving on testing time and costs.

Modeling to Save Time

For example, if a new federal regulation were introduced, and several new pieces of information had to be logged for loans of a specific size (or greater), the domain model might show:
- That some information was already being collected and only needed minor updates.
- None of the information was being collected at that size loan; but it was for a different size, and that function could easily be added to that section of the application.
- That data wasn’t being collected on loans of any size, and a conversation might ensue to determine if it was worth including the same data requirements on loans other than newly regulated.
- That information could be calculated based on existing procedures and would only need to be accurately logged and kept.
Surely, a model is only useful so long as it’s current. Any changes to the application need to be entered into the model. An outdated model can be worse than having no model at all since conversations that occur around it are started with false data and assumptions. If a model isn’t maintained, then all of the organizational time and effort that went into it and shared knowledge it created are lost.

Maintaining the model is key to ensuring its usefulness long after it is first “complete.” Once a model is created, it also can be helpful for the members of the modeling team to present and discuss it with their department coworkers. Sharing knowledge beyond just a few people ensures that no matter what personnel changes happen or what development trends and methodologies are implemented in the future, the model can carry on and maintain usefulness as a teaching and documentation tool.

Modeling for Operations

As applications and infrastructure become more and more intertwined, it becomes critical that both Developers and Operations are involved with creating an application model. Any changes that will be considered based on the model will have to take into account factors such as security, application monitoring and the host of other criteria that Ops deals with.

Designing Changes with Devs and Ops

When evaluating an organization for a loan, the credit rating of that organization will need to be acquired. There are vendors that perform the task of rating other organizations, and individual banks will have preferred vendors for that metric.

If the task of gathering these ratings were to be automated, a developer might want to implement a simple process wherein the application queries the vendor through its API and waits for a reply. This is simple and straightforward, and only requires two pieces of data: the query and the report. However, Operations would certainly step in because this scenario would be a security risk. It would either involve two-way communication or require leaving the communication channel open for an extended period of time.

A better solution that could be created with input from operations might involve an additional piece of data: a query ID. The interaction would then consist of multiple steps such as a query being made, a query ID getting returned and, then, at regular intervals, the vendor being sent the query ID until the report is ready.

Operations will be involved in the application development, either from the start where it can help define practices and procedures that the development team must follow, or before the application is released and it raises red flags and security issues the development team must comply with before the changes are released. It’s much more efficient for Operations to be involved from the start.

Get Modeling

Organizations have proprietary software because it is a competitive advantage for them to create their own applications based on their business needs. Because business needs are constantly changing and evolving, the software that encompasses them must change and adapt as well.

Finding methods that allow for quicker changes while ensuring better change quality should be a goal in any organization. Creating an application model, and the shared understanding that goes with it, can be an invaluable part of any application that faces maintenance or overhaul.

About the Author / Scott Reece

Scott Reece is a huge fan of the greater visibility and communication enabled by DevOps. As a Friend of Astah Scott has been successfully closing project communication gaps by using models and team building. With more than 10 years of project management experience, Scott currently serves as a Partner Director at Inedo.
August 16, 2016
The ‘Continuous’ Illusion

Continuous delivery is an illusion. That doesn’t make it insubstantial—illusions can have a tremendous impact. Like the first motion picture: the locomotive felt so real to first audiences that they fell from their chairs, screaming. But of course, the locomotive was an illusion, merely rushing past on screen.

A good magician, like a good inventor, will tell you that the secret to a powerful illusion is hard work on top of a good idea. Indeed, good magicians and inspired technologists have a lot in common. Each is always on the hunt for the next big insight, the transformative angle, building on existing industry techniques to create something even greater. But each knows the secret to truly wowing their audience, whether for a one-night-only show, or an ongoing relationship. What really gets the job done is the vast, complicated, hard-won machinery ticking away behind the scenes.

Today’s No. 1 magic trick for making great applications, a directive now pervasive across every industry, is continuous delivery. Right now, continuous delivery provides that wow. It takes app updates from a customer stumbling block to a seamless benefit. It takes feature delivery from “maybe in a year” to “is tomorrow soon enough?” It allows Dev teams to wave their magic wands and transform the impossible into the effortless.

And, of course, continuous delivery is an illusion. Remember that movie locomotive, leaping out of the screen? Every instant of its motion was its own little frame of celluloid. And the true magic was the process that bound each and every frame together, delivering them onto the screen with perfect timing.

Continuous delivery is the very same sort of illusion. The steady stream of new features, new capabilities and bug fixes must be created one by one by a vast army of talented developers—not unlike the thousands of talented stencilers who first brought color to motion pictures. And the true heart of the process is the automated systems that support this army, and which ensure the coordinated delivery of its products to the end user.

The heart of continuous delivery is the machinery of automated testing and deployment. The approach behind continuous delivery encourages teams to produce software in short cycles, ensuring that the software can be reliably released at any time. For these releases to be reliable, continuous testing is integrated into the software delivery pipeline, for immediate feedback on any bugs an update would generate. Then, when a proposed change has passed the automated tests, it is deployed to production automatically. This software development life cycle (SDLC) allows companies to achieve the business goal of truly responsive development. The team sees an opportunity, confirms the solution and then delivers that solution to customers extremely rapidly.

Each stage of continuous delivery—develop, test, deploy—has its own technical challenges, but the testing step in particular poses a unique bottleneck.

In the development stage, developers primarily require code. Code is relatively lightweight, and can be managed through industry-standard tools such as Github. Developers need their laptops, but in general code management poses a limited operations support challenge.

The deployment stage can be more challenging for ops. The newest version of the code must be deployed to a wide population of final platforms, which may vary in hardware, software, location, permissions and so on. However, the target systems are at least those in ordinary use. The server the new page runs on or the smartphone that installs the application update are pre-existing systems, and they are managed by their users. So Ops teams are not required to support specialized hardware to deploy. Furthermore, in the past few years a number of innovative technologies, such as Ansible and Docker, have emerged to simplify this process further.

Testing, on the other hand, combines the challenges of both of these stages. Continuous testing requires dedicated resources for developers and QA. But these resources are full-scale application environments, including not just code but data, operating systems and even appropriate hardware. And because best practices encourage developers to write new tests for all new code, the amount of regression testing required for every code change can only grow. That means that testing must grow ever more parallel, or suffer increasing delays—and any delay in testing can undermine overall continuous delivery.

To preserve the Continuous Illusion, a development team needs on-demand access to scalable testing environments, including their data. Data in particular is often overlooked in test environment creation, but it must be delivered to every test instance. That means test data management (TDM) is an inescapable part of any successful continuous strategy.

TDM is relatively self-explanatory: it refers to the process of creating, managing and delivering production (or production-like) data to non-production data environments. Every organization does some TDM, though many do not consider it a separate practice. But to achieve the sort of seamless efficiency that can support the Continuous Illusion, teams must adopt a modern TDM practice.

Legacy TDM relies on multi-stage, manual delivery chains. Developers and testers file tickets, and then they wait. Storage admins, DBAs, backup admins, security personnel and other staff each have to spend a huge portion of their time servicing the ever-growing stream of tickets, handing off environment creation from one function to another. Meanwhile, developers and testers are left in the lurch, and continuous delivery grinds to a halt.

Once, this process might have been unfortunate but necessary, imposed by technological restrictions. But modern solutions can tackle these challenges and overcome them. Too often, teams with poor TDM have simply neglected to implement the solutions that they need.

The most effective TDM practices will use a data management solution on par with other continuous delivery pipeline tools. The TDM solution will be able to stand up data environments in minutes and at massively parallel scale. It will rely on production data and automatic security, rather than synthetic data generation or data subsets (both of which requires substantial upfront planning and cannot hit the full suite of edge cases). It will integrate readily with existing continuous delivery workflow tools, allowing data to be automatically provided whenever a test job runs.

There are some solutions in the market today that meet these criteria. Adopting one can represent your opportunity to tighten test cycles and deliver code faster—regardless of how fast your software timelines are today.

To deliver the Continuous Illusion, every component of the continuous delivery pipeline must be operating at peak efficiency. A powerful TDM solution is a key requirement for allowing your customers to sit back, relax, and enjoy the magic of your product.

About the Author / Louis Evans

Louis Evans is a DevOps evangelist with Delphix. He’s excited about the potential for superior TDM to enhance overall software quality. He is a huge Alan Turing fan, and partial to a well-placed semicolon.

August 15, 2016
8 Reasons to Go ‘All In’ and Attend Jenkins World

Jenkins World 2016, the world’s largest gathering of Jenkins users, is coming to the Santa Clara (California) Convention Center, Sept. 13-15. The lead organizing sponsor is CloudBees, along with a number of premier Jenkins ecosystem vendors including BlazeMeter, Undo and Black Duck. Jenkins World will offer attendees opportunities to learn, explore and network. This year’s theme is “All IN” as Jenkins users, experts and thought leaders prepare to go all in on DevOps.

Need more convincing? Below are eight reasons to go all in at Jenkins World 2016:

Hear keynotes from industry leaders — Kohsuke Kawaguchi, founder of the Jenkins project, kicks off the conference with the opening keynote this year. Other keynotes include Sacha Labourey, CEO of CloudBees, and Gary Gruver, former DevOps exec at Macys.com and HP and industry author. Rumor has it that Gene Kim may make a guest appearance, too!

Attend training/workshop add-on options — Come to Jenkins World as an attendee, leave as a Jenkins master. Join us a day early to attend Jenkins certification training and/or learn the fundamentals of Docker and Jenkins. Additional workshops, covering topics such as plugin development, Jenkins certification and automating pipelines with the Pipeline plugin, are available.

FREE certification! Your Jenkins World registration also provides you with the option to take a certification exam completely free! Did we mention it was FREE? All you have to do is sign up and study up!

Brush shoulders with the Jenkins stars — Get access to some of the best Jenkins experts in the world; attend their sessions and network with them. The sessions cover a range of topics including infrastructure as code, security, containers, pipeline automation, best practices, scaling Jenkins and community development projects.

Visit a variety of vendors — At the expanded Sponsor Expo you can check out a range of technologies and services that help you optimize software delivery with Jenkins.

Pick up your next read — CloudBees Senior Consultant Viktor Farcic has recently published his book, “The DevOps 2.0 Toolkit: Automating the Continuous Deployment Pipeline with Containerized Microservices.” Be one of 200 lucky attendees to get a free copy and be sure to catch his session Sept. 13. We will even be hosting a book-signing with Viktor.

Do you follow CommitStrip? They will be onsite and you can help them paint a custom Jenkins-themed mural!

Meet the Butler and snap a selfie – You may have seen the Butler on @CloudBees engaged in some Xtreme social media adventures to get himself to Jenkins World, but at Jenkins World you’ll have the chance to meet him in person. Don’t forget to snap a pic with him at the social media station and share with your friends.

All of this and so much more awaits you at Jenkins World. Go “All In” and register now! Use this code JWDEVOPSCUST and get 20 percent off your conference registration.

See you in Santa Clara!

August 12, 2016
Test-First Development: Processes and Tools for Success
A lot of software development teams are talking about “test-first” methodologies. The practice involves moving testing up into the very earliest stages of development so automated tests can be written before code. Making this seemingly minor shift can result in much higher quality software and greater efficiencies. Integrating development and testing avoids needless late-stage bugs and complicated redevelopment efforts. It can help software development organizations focus on usability and features and achieve faster time to market. And because of test-first’s reliance on automated tests, organizations gain reusable tests, saving time and increasing standardization for testing and quality assurance overall.

It’s no surprise, then, that 51 percent of organizations have begun using test-first methodologies, including 37 percent in the past year, according to a recent global survey of 200 software testers conducted by our company. But, despite the enthusiasm for this practice, there are concerns: 44 percent of survey respondents said their biggest fear about moving to this approach was forcing developers to contribute tests prior to completing code, while 19 percent said they worried about removing traditional testing checkpoints on the way to production. Other barriers include the lack of standard practices or tools. That said, test-driven development promises to bring ample benefits to software development teams, the business and, importantly, customers.

Test-first development is recognized across three broad terms today: behavior-driven development (BDD), test-driven development (TDD) and acceptance test-driven development (ATDD). TDD is an umbrella term for the practice, although it has traditionally focused more on technical, unit testing. BDD and ATDD incorporate user requirements and business benefits along with technical testing. BDD differentiates through its adoption of specific automation frameworks and language for writing and running tests.

Key Changes for Successful Test-First Development

Getting started requires change across a few critical areas for most teams. First, evaluate your team for hiring and skills training needs. On the one hand, developers will need to learn basic testing skills, so they can write good tests and run tests before they develop code. Meanwhile, testers must become more proficient in automated testing tools, which usually entails acquiring a fundamental knowledge of programming. Many companies will need to hire key contributors from outside; in which case, leaders should look for well-rounded individuals with past experience using test-first methodologies successfully. An individual who is an expert at one skill, or who is too independent and can’t collaborate well, won’t be an ideal member of a team experimenting with test-first approaches. Leaders also may need to adjust by balancing the ranks more closely between developers and testers so that one group doesn’t rule over the other. Hiring additional experienced testers frequently will be necessary.

Training of existing staff is paramount, best achieved through a combination of methods including internal training, mentoring, online courses and paired development, where developers and testers can sit side by side and collaborate. More than half of the survey respondents said developers and testers would be jointly responsible for automation test creation within their organizations.

Beyond cross-training, the cultural challenge of moving to test-first methodologies can be overwhelming. It requires the development of incentives for creating quality products, not just delivering new features at speed. It requires an appreciation and respect for the practice of testing. Unfortunately, testing too often is viewed as a necessary cost of doing business, rather than bringing a clear benefit to the organization and its customers. That mind shift is not only inaccurate, but it doesn’t fly with progressive, Agile thinking. It will take strong leaders to help traditional teams understand the need to change and modernize practices. A leader may forego the buy-in process and instead decide to lay down the law to staff: Staff must move to TDD or BDD, or else. But the results won’t be ideal. Smart developers will find loopholes, such as writing tests that aren’t comprehensive or fully aligned with project goals, so the code will pass more quickly.

On the process front, organizations that have moved or are moving from Waterfall to Agile and DevOps will have an easier time adopting test-first methodologies. In fact, it’s pretty difficult to implement test-first processes and tools in a Waterfall environment because of the siloed nature of functions and the long release cycles. The survey results support this premise: 55 percent of respondents said their testing process was Scrum/Kanban-driven before transitioning to test-first, while 21 percent said their approach was iterative-requirements driven and 18 percent was Waterfall-requirements driven.

Along with that shift, test-first teams will need to adopt new metrics that align with this new way of doing business. Instead of looking solely at velocity, development leads should measure how long it takes the team to move a product from feature approval to code release. With a focus on quality and testing, companies also should measure and improve upon bugs, such as number of severe defects post-production. Those types of business and customer-oriented metrics align with the new set of Agile metrics that that many teams are working for today.

Test-first teams will need to adopt DevOps toolsets, which are designed to push code out to the pipeline faster. Specific technologies that go hand in hand with test-first development include:
- Continuous integration (CI) platforms such as Jenkins and Team City, to assist in running the automated tests immediately for quick build feedback.
- Container technology for rapid deployment of test and pre-production environments, to capitalize on having features production-ready soon after coding.
- Test management platforms including qTest Scenario or Cucumber Pro.
- Test automation frameworks including Cucumber, SpecFlow , and other open source tools which enable easier support for customization and collaboration.
There’s a lot to think about when moving toward test-first development. While it may seem overwhelming at first, all of this is achievable in a reasonable time frame if you have the right dedicated resources to see it through. One-third of survey respondents said it took them less than three months to complete the transition to a test-first approach, while 30 percent said it took less than one year. The payoff for software teams, in terms of improving quality, customer experience and reducing costs of innovation, can deliver higher customer loyalty and even faster growth in the marketplace.

About the Author / Kevin Dunne

Kevin Dunne is vice president of Business Development & Strategy at QASymphony.
August 12, 2016
Why Your Organization Needs DevOps

The recently released fifth annual “State of DevOps Report” by Puppet has once again brought with it fresh insights into what drives high-performance teams. The report, which comes at a time when DevOps has ceased to be a buzzword, provides proof of why more and more businesses across the world are adopting DevOps to improve their organization’s performance, revenues and profitability. DevOps has truly come of age and this year’s “State of DevOps Report” clears any doubts fence-sitters may have about the effectiveness of the DevOps approach.

The 2016 report reasserts that unparalleled IT and organizational performance is a result of a team effort spanning development and operations. The report also highlights the importance of improving the entire product life cycle—from initial product planning, to quality and security assurance, to customer feedback—to speed up delivery while improving quality, security and business outcomes. You can read the full report here.

In today’s competitive business environment, DevOps has emerged as a vital solution that helps organizations meet ever-growing industry demands. The “2016 State of DevOps Report” helps us understand how the practices associated with DevOps affect IT performance and organizational performance. Let us examine the findings of the report to ascertain how DevOps can benefit your organization.

Why Does Your Organization Need DevOps?

The “2016 State of DevOps Report” makes it plain and simple that companies that incorporate DevOps practices get more done. According to the report, high-performing IT organizations deploy 200 times more frequently than low performers, with 2,555 times faster lead times. They have 24 times faster recovery times and three times lower change failure rates. High-performing IT teams spend 50 percent less time remediating security issues and they spend 22 percent less time on unplanned work and rework, the report states.

Performance

If we boil down the report findings into actual benefits of adopting DevOps, we could say that DevOps enables continuous software delivery with less complex problems to fix and faster resolution of problems. This essentially means that you can deploy faster and more effectively in more stable operating environments and add value rather than just fixing or maintaining.

DevOps can revolutionize the performance levels of organizations and allow them to deploy at a rate never seen before. It has certainly enabled organizations such as Etsy, Netflix, Facebook, Amazon, Twitter and Google deploy hundreds and thousands of code per day while delivering world-class stability, reliability and security. You can find out how different organizations have implemented DevOps to their benefit in this YouTube video.

Security

Higher performance is not the only payoff in the DevOps culture. Organizations that adopt DevOps practices are known to have better information security. The “2016 State of DevOps Report” clearly states that organizations that integrate information security objectives into daily work spend 50 percent less time remediating security issues than low performers. This has a positive impact on IT performance and security outcomes.

Any organization, irrespective of size, can employ DevOps to achieve high performance levels and meet business goals while cutting down on costs related to fixes and remediation security issues.

How DevOps Transforms Teams

Consider this scenario: In an organization that does not apply the DevOps methodology, the development team writes code and develops a product, which is then sent to the testing team that verifies if the code meets the requirements. The operations team steps in to run the product only after this process is complete. The DevOps philosophy was created to break the silos that teams operate in and effect better collaboration and performance.

The culture shift DevOps brings about in organizations is substantial, and since culture is a key factor responsible for a company’s performance, application of the DevOps philosophy provides measurable and non-measurable results. A few of them are:

Employee Engagement

DevOps is neither a method nor a tool, it’s a culture! In organizations that observe the DevOps culture, the development and operations teams work outside silos, releasing products faster, thereby increasing operational efficiency. This is made possible by the operations team giving the developers constant feedback about the code and troubleshooting problems with the user experience in mind. This continuous learning and delivery practice allows cross-functional teams collaborate as one team with one goal, thus facilitating higher performance levels. The improved organizational culture and enhanced employee engagement can help organizations not only in retaining great talent but also in recruitment.

Organizational Success

The “2016 State of DevOps Report” effectively explores the relationship between employee engagement and organizational success and goes on to show that there is a strong correlation between these two factors. The report states that employees in high-performing organizations are more than twice as likely to recommend their organization to a friend as a great place to work.

Organizations can greatly benefit from adopting the DevOps culture. The “2016 State of DevOps Report” shows that high-performing organizations are widening their lead against lower-performing organizations. This can be attributed to the increased productivity and creativity of highly engaged employees that helps them provide better experiences to customers.

Organizations can achieve great business results by reinvesting the human time, creativity and energy saved by reducing rework and downtime through DevOps. Herein lies the ROI of DevOps—the competitive advantage that organizations get by investing in a philosophy that positively affects bottom-line results!

About the Author/ Pallavi Poojary

Pallavi Poojaryis a writer with Edureka, an online learning company with more than 250,000 learners spread across the globe. She writes on hot technologies and skills that are in demand today, including DevOps, Big Data and Project Management, to name a few. She is a believer in transformation of careers through learning

August 11, 2016
Should You Embrace DevOps in Your Business?
New to some, old hat to many and a source of ambiguity to more than a few, DevOps is being embraced by the IT world as an answer to increase quality of business processes—to innovate faster and to get new products to market sooner in a defined time frame. There is no doubt DevOps has fundamentally changed the way an IT organization works and how it gets things done.

But one may argue what, exactly, does it mean? Is it a process? A methodology? A paradigm? A platform? A technology or a culture? DevOps is not a platform or technology, but a practice that requires internal cultural changes where working together is encouraged to reduce complexity and remove the siloed setup while ensuring the stability of service delivery.

In simpler terms, DevOps is an evolution of agile software development that aims to break down the “wall of confusion” between developers (Dev) and operations (Ops) team to collaborate better so they can deliver frequent changes faster, with higher efficiency and robust quality based on market demands.

Let’s have a look what Gartner has to say:

“DevOps represents a change in IT culture, focusing on rapid IT service delivery through the adoption of agile, lean practices in the context of a system-oriented approach. DevOps emphasizes people (and culture), and seeks to improve collaboration between operations and development teams. DevOps implementations utilize technology — especially automation tools that can leverage an increasingly programmable and dynamic infrastructure from a life cycle perspective.”

Once you have a firm grasp of what it is, we can move forward. The critical step is to assess your business environment and processes for DevOps compatibility. The assessment questions could be:
- Are you meeting your project timelines?
- Are your build, deploy and test processes automated?
- Is your development and delivery cost rapidly increasing?
- Do you need more stable operating environments?
- Do you want to improve customer satisfaction through frequent and timely updates, immediate feedback loops and continuous improvement?
- Are you ready to break down the traditional silos across teams and ready to go faster?
If you’ve answered “yes” to any of these questions, then you may want to consider DevOps as a service for your enterprise. But before you consider it, the critical first step is to research your consulting partner. Look for a partner that has a long-term vision and a clear, tightly integrated road map to help your business realize the true benefits of DevOps. So whatever your drivers are for undertaking the initiative, your partner should have the requisite skills and experience to guide you on your journey. Alongside, your partner should offer you a complete range of services. From initial discussions through to delivery and ongoing support.

There’s a lot to be said for DevOps. In a business climate that’s all about speed, quality and delivery, it’s critical that enterprises understand the power of DevOps. It is not a fringe movement; it has now become a key part of enterprise IT planning to stay relevant in the marketplace.

About the Author / Ritesh Gujrati

Ritesh Gujrati is digital marketer at OSSCube, a global solution provider. He frequently talks about disruptive technologies like DevOps, digital transformation, big data, IT modernization, IoT and cloud. He is well-versed with web analytics tools, paid media marketing and has hands-on experience on organic promotion and content marketing. Feel free to contact Ritesh through ritesh.gujrati@osscube.com.
August 8, 2016
DevOps: Keep the Business in Business
I remember when data centers were not the multipowered, multitelecommunication, hardware, software and people buildings they are today. My first was on the fifth floor of a parking lot and the cars drove around us. The importance of IT, while seemingly crucial to the business functioning of the third largest bank in the great state of Texas, was not deemed significant enough to have a modern data center.

Texas is in the hurricane belt, so five to seven months a year we play hurricane roulette. One year our city was enveloped by a Force 4 hurricane, which we survived. Our competitors, already hit by various economic factors, did not escape. But the good news was that the bank allowed us to build a proper data center.

Business continuity management (BCM), or keeping the business in business, is not just about disaster recovery. BCM is governance on risk, management of what happens if you are in the news the wrong way, employee-handling, decision-making … well, everywhere, really that keeps a business in business. Beyond people and buildings, technology is the main ingredient of enabling a business and should strongly contribute to any BCM effort.

DevOps and BCM

The concepts of DevOps are not new: How do you best manage the technology (people, processes and the fun stuff) that enables a business or mitigates obstacles? By blending the practices from Agile, Lean and ITSM, you create a better, faster, safer way of working across the organization.

If technology sustains and improves business processes and customer products, then it stands to reason that DevOps and business continuity work hand in hand.

DevOps encourages you to think in terms of the entire value chain of events. Release management, for instance, is the chain of events that ensures what is being created is delivered for use as soon as possible and with high quality, and is able to be supported. Sometimes, processes work together such as budgeting (how to use money and other resources) and funding (using money or other resources).

If you use Agile practices, then you already have the basics of release, deploy, test, change and support processes integrated. Why not add an aspect of BCM to your functional requirements and user stories, or to your “what happens if” scenarios? In this way, from the beginning of the chain to the end, everyone involved can look for, design against, test and be ready to support those occasions.

Metrics

Ranger4’s favorite metrics are cost of delay to help prioritize and meant time to recovery (MTTR) to ensure that the response, review, repair, recovery and return are as quick as possible. Great metrics impact decision-making immediately and drive change in behavior.

BCM can help to underpin these metrics by asking:
- Events will happen, so are we ready?
- Where is our code? What is our plan for infrastructure/cloud?
- How long can we be down and how long to recover?
- Where are our suppliers? What happens if they cannot respond?
- What if our data center is down but the business is forced to evacuate?
- Where are our documentation checklists? Remember that plane that landed in a river at New York seconds after lift-off? Not a long time to read a manual, so we need an easy and automated checklist.
- How will employees service their staff and customers in the event of an event? I know from firsthand knowledge that the first thing taken away from companies in a major crisis is mobile service, as almost all bandwidth goes to emergency services. So what will you use?
- What happens if a political event occurs, such as Britain leaving the EU, for example?
- How will customers contact us? How will we respond?
Answering these questions will keep the flow of technology able to service the business with the right level of feedback and response. If you continually look for ways to improve business processes using technology, then you have started to mature DevOps and the use of the three ways—and, more importantly, you have impacted the culture, automation use, customer-employee focus, ways to measure and the sharing of knowledge to make you better, faster, safer.

Being able to prove that you can survive is a great way to impress current and future clients. Every day there’s news about a company that lost a component of its technology or was impacted by an event. How often do you ask yourself: Where was their BCM strategy?

About the Author / Daniel Breston

Daniel Breston is the Chief of DevOps Transformation for Ranger4. Daniel has 30+years leading IT Service, Operations, Applications, Data Center and service partners in management of technology enabling business processes and functions. He has also spent 15 years of consulting and coaching leadership teams across the EU and UK in developing their people, processes and use of technology to deliver technology services better, faster, safer. Daniel has qualifications in IT Service Management (ITIL, COBIT,etc.), Lean and DevOps.
August 8, 2016
Pokémon Go Shows DevOps Changes Human Behavior

Everywhere you go lately, you can see people acting strangely. They’re walking streets they never walked before. They’re waving their smartphones around in odd ways. And they’re high-fiving each other for no apparent reason.

And they’re doing it because of DevOps.

Of course, not everyone immediately thinks about Pokémon Go as an artifact of DevOps—but that’s what it is. It is code written, continuously modified and continuously promoted to production based on changes in workload performance and user feedback, implicit and explicit. It is also the most downloaded app on iTunes ever.

More importantly, Pokémon Go is visibly changing human behavior. That’s something worth considering as organizations seek to survive and thrive in the application economy.

Doing Things Differently vs. Doing Different Things

Most development is done so that customers or employees can do things differently. There are lots of apps that make shopping easier or deliver better analytic insight for decision-making. And those apps certainly provide business value by removing obstacles to revenue or by helping companies optimize allocation of resources.

But Pokémon Go doesn’t merely allow people to do something differently. It drives them to do something entirely different—location-based and augmented reality gaming.

Pokémon Go isn’t the first or only app that changes human behavior. Uber and Zipcar changes how we get from place to place. Square changes how we do retail. Pokémon Go, however, is an especially dramatic manifestation of how apps change behaviors. People are doing something they’ve never done before because of some software—and because that software “went viral.”

That’s an important concept to bear in mind as organizations seek to optimize the effectiveness with which they leverage technology in their businesses. Are you just trying to write apps that help your users do something a little better? Or can your apps enable and inspire entirely new behaviors that people will find worth embracing—and therefore will also promote across their social networks?

The Role of DevOps

DevOps is central to this endeavor in several ways. First, when you’re doing something new, you by definition don’t know what you’re doing. So you have to keep going through cycles of testing to get things right. If those cycles are slow and you don’t take the time to test all possible use cases—such as geolocations, devices, operating systems, hardware, diverse transaction, etc.—because you have trouble putting the right test data together or it takes too long to provision the necessary environments, you will either be late to market or release something nobody likes.

To avoid these types of pitfalls, you need a streamlined and automated end-to-end DevOps pipeline that optimizes your delivery value chain and eliminates constraints and dependencies across the software development life cycle. Implementing this type of continuous delivery tool chain will allow your DevOps teams to continually improve the quality of your applications in a shorter time frame.

Second, even once you get things right, they won’t stay right for long. The folks at Niantic were most certainly surprised by just how viral their app went, so they had to scramble to overcome performance issues in the field. They also are dealing with some negative feedback from true Pokémon aficionados who are not so smitten with how gameplay diverges from their long-beloved Nintendo brand.

Niantic’s ability to keep riding its initial viral download success will be closely tied to its ability to address these issues. And that’s also best done with an automated DevOps process—along with Agile disciplines—that allow the company to keep refining both its code and the way that code runs in production and ensuring the performance of the IT infrastructure that supports the user experience of the app.

Luring the Wild ‘Customon’

Perhaps the most powerful lesson from Pokémon Go isn’t for developers. It’s for business leaders. Unfortunately, many non-IT executives still view DevOps and related investments in digital capability as an operational issue for technologists—rather than as an existential issue for the business itself.

But it is decidedly the latter. Pokémon Go isn’t just about having a good idea for a game—any more than Dollar Shave Club, which Unilever just bought for $1 billion—it’s about having a good idea for a company. You have to be able to execute. And in the application economy, you can’t have execution with speed and quality without DevOps.

So if you’re still struggling to get upper management to invest in funding your DevOps initiative, maybe it’s time to put away the PowerPoints and pull out the Pokémon instead. We’ve rarely had a more dramatic example of how applications can impact human behavior—and how the ability to get code into production quickly and successfully can impact your business.

About the Author / Aruna Ravichandran

Aruna Ravichandran is vice president of DevOps Solution Marketing and Management at CA Technologies, responsible for cross-portfolio solution marketing for DevOps across the Application Performance Management, Infrastructure Management and Continuous Delivery product lines. Before joining CA Technologies, Aruna held several management positions in product marketing and engineering at Juniper Networks and HP. Aruna earned an MBA and master’s degree in Computer Engineering from Santa Clara University and holds a Bachelor of Science degree in computer science from Bangalore Institute of Technology.

August 5, 2016