devopsy.kinsta.cloud

Category: Doin’ DevOps

Why your Company Should Load Test

The main reason your company should load test its websites and mobile applications is to learn how the site performs so you can improve the user experience and make smart web infrastructure decisions. Sounds obvious, doesn’t it? Above all else, load testing is a learning experience that provides a wealth of insight into how your website performs from both a user experience and technical perspective.

How can it be done? Running a load test involves creating a small or large number of virtual users via programming script, running a simulation in which those virtual users access your site, and gathering information about how well the website performs under the traffic load.

How Your Website Operates and Why it Matters

If you are curious to learn more about how your website operates, contact a specialized load test company that offers load tests with up to 50 users for free over a 30-day period. Such a smaller test will provide insight into how well your company’s site performs for a typical user during light traffic situations. Free application monitoring tools often can be downloaded if your business does not already have one.

Longer load times hurt conversion rates: According to Amazon, every 100ms of page load time latency reduces sales by 1 percent. So your business could be losing out on 10 percent of sales because your pages take a second longer to load. Testers can learn all sorts of interesting things about how a site operates with varying virtual traffic loads.

Primarily, the load test tells you how long it takes a page to load on your site for users at different traffic levels. You can find out how quick load times are during normal, peak, spike and overwhelming use rates.

The load time data helps identify not only problems in your website code that could be slowing down individual pages, but also problems with the infrastructure itself. Load testing lets your business know exactly how much load times increase when the site gets busy relative to normal use. The tests also can determine how much traffic a site’s infrastructure can handle before load times get outrageously high—and when the site will crash.

Proximity Performance

A load test provider can offer testing from server locations all over the globe. A guest in Chicago visiting a site that is hosted in New York City may have fast load times, but Los Angeles-based visitors may have to wait an extra second for pages to load. This data can help your company make an educated decision when purchasing a content delivery network (CDN) service that mirrors content, so site guests farther away from the original host server have a better experience with your site. Look for a load test provider that can offer synthetic load traffic of up to 500 Gbps bandwidth and a million concurrent virtual users. Loads should be generated to your breaking point, and fast!

Get the Ideal Amount of Power and Learn How to Scale

Once your business is able to see how your site performs under various traffic loads, that information can help determine where the infrastructure needs upgrades at various traffic levels. This helps with capacity planning—the ability to scale different infrastructure elements to meet demand without wasting money on power that is not going to be used.

Running load tests on your company’s site will teach you invaluable information about how your site works so your customers can have a better experience with your platform. Improved website performance equals improved business.

About the Author / Sven Hammar, CEO, Apica

Sven Hammar is co-founder and CEO of Apica, a provider of powerful, best-in-class technology for testing, monitoring, and optimizing the performance of cloud and mobile applications. Mr. Hammar he has decade-long experience and expertise in web performance and web optimization, e-commerce, cloud services, IT entrepreneurship and the Internet. He is also a serial entrepreneur who has founded several successful IT companies over the years.

August 24, 2016
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
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
Checks and Balances to Build Stronger Code

Every software development needs coding; without it, nothing can be developed. The quality of the software depends on the way its developers write code. It’s an essential part of the system and the behavior of the system depends on it. A small mistake in coding may make the software vulnerable and unstable.

Quality engineering works hard to find bugs to avoid potential problems with the software. QA engineers spend numerous hours and put tremendous effort into finding any problems with the software and reporting it to the developers.

Cost of fixing the defects at various level.

The cost of fixing defects at a latter stage increases exponentially; hence, you need more hours of QA engineers and developers to fix and run the entire release cycle again. If we can save some amount of time and effort, we can utilize resources in a more productive way.

Can we make sure code is better-written, more tightly secure and has no potential bugs, and the right libraries are used?

If we can implement it, we can at least make sure developers are checking to make sure there is less friction in the code?

Here are few checks that can be implemented during creation or before passing code to QA to ensure it’s less buggy.

Code Review

In code review, the coder sends it to someone else for the review. It’s really a great way to verify the written code by a second pair of eyes to catch any glitch, logic or possible mistakes overlooked by the coders.

This is part of the development process to make sure nothing is released without a second opinion. There are many ways and tools available to perform code review. These can be implemented and integrated with the source control tool. More on code review and details can be found here.

Unit Test

Unit testing tests a piece of the code by writing small code around it via supporting data and mocking it to test scenarios. It commonly is written by developers during the development, then run during source code compilation or independently according to various languages.

This testing provides extra early warning to find problems before handing it off to quality check. Unit test coverage could provide details on how much has been covered by unit test cases. There are many ways to figure out the coverage.

Static Code Analysis

Static code analysis is the way to analyze at a very basic level without running the software or performing any testing. It can be done at compilation time or at development time by using client-side tools.

Analysis tools look for any possible or hidden bugs, such as never-ending loops, or programming flaws. These tools do analysis based on a similar pattern but each in a slightly different way.

Coding Guideline

Each developer may write code in his/her own style with varying degrees of differentiation. This may create big problems when it comes to handing over of a project to different teams or coders. It may take tremendous amount of time to understand what’s been written by somebody else.

To reduce this potential headache, organization may implement a coding guideline, or style of writing code for developers, to make sure everybody follows one systematic way that can be understood easily by other team members. There are different tools available for various coding languages.

Library Check

Open-source projects and other freely available tools in GitHub are making life easier for developers to use them in their projects as libraries. At same time, they can introduce several other problems with the software if libraries are not tested properly, including security vulnerabilities, untested components or licensing issues.

There are many tools to help developers to verify their libraries.

In Summary

There may be many other verifications and checks required by an organization. Above are the very basic checks that can be implemented during the development phase to rule out any discrepancies related to security or legal issues. Checks could be implemented at the client side, where developers write code or during the continuous integration phase.

There are many tools available in the market or the open-source community that can be used to verify and secure code to avoid unrealized bugs. It’s in the best interest of any organization to keep its software bug-free and reduce the amount of unnecessary resources working on such issues that could be caught early.

Other References – http://www.scmtechblog.net/2016/08/code-quality-check.html

August 9, 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
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
An Even More Modern Continuous Integration

It would be strange for me to tell you that there is an even newer new approach to release automation, as if the processes of continuous integration (CI), continuous delivery (CD), continuous deployment and canary releases were not modern enough. And it would be even stranger to say that the open-source tool Jenkins, which dominates more than 60 percent of all release automation processes, is not enough for some, according to Salesify. But right now, I’m going to make the claim that all of the above is true.

DevOps teams are impatient. They always want better. It is part of the enthusiasm that continuously pushes the modern delivery chain forward. But, of course, this change has to be throttled. This is why I look to companies who have found the proper mix of sustainability and modern tooling. When I met with TapInfluence, I was surprised to find out that even the “modern” tools of 2015 are not enough for the demands its applications are putting on application releases. And its new delivery chain is a powerhouse for releases and quality.

Tapinfluence is a SaaS platform for initiating and managing influencer marketing campaigns. The company has 60 employees and growing with engineering based in Mountain View, California, and HQ in my home state of Colorado. Up to this point, the application has grown organically from a minimal viable product (MVP), which was driven primarily by a stream of requirements that came up and then adopted, to an established web application built on modern development principles. The incremental improvements are in the spirit of modern development, but it did not make for a sustainable delivery chain—or a delivery chain at all. The company lacked the practices of release automation and infrastructure you would expect.

That is why when Tapinfluence raised its latest round of funding, it was not only meant to grow sales and marketing. The funding was also intended to build a more mature development operation to keep up with the growth of the platform and make sure all the new functionality did not come with technical debt.

Kabriel Robichaux became the first director of engineering, and boy, did he have a lot of cool stuff to bring with him. Nearly from day one, Robichaux was preparing for team growth (from four to an estimated 20 team members in the next year), and significant changes to modernize the infrastructure and processes in the existing development team. This included Docker and a new release automation tool called Codeship. It was Codeship that got my attention.

Robichaux had a lot of experience in releases automation already. “I have lots of experience with Jenkins, but working in a startup, a hosted CI solution was a key feature.” But, of course, cloud-based is not the only thing. After all, you can put Jenkins in your own cloud fairly easily.

But Robichaux’s top considerations went beyond the purely technical and into their relationship to the community. He explained to me that when he adopts tools, he finds alternatives to the most popular tools, and checks them all out. He looks at tools from not only the perspective of their core functionality, but also whether they are committed to growing the market.

So we’re not talking about a new generation of release automation. Release automation is just a workflow tool. It is how the tools approach the market. And it is a tremendous coincidence that he works for an influencer marketing company, and made a deliberate choice to look at how Codeship influenced the market. “I loved Codeship because they have an opinion, they are consistent with it, and they share it. For example, they believe that everything should be in source control, and so do I.”

Considering that I work for a company rooted in developer communities, I have seen this social aspect of tool adoption as well. And it is growing rapidly. Given all the noise, it is not enough to have one or two features that do things better than the other guy. You have to be something more than a product or brand. Getting back to tactics, full control as also imperative.

He said, “I need to be able to customize everything without jumping through hoops. I want to launch it, get to the terminal window, and start adding steps. The release automation tool, if working properly, should be transparent. I want to focus on the steps in the process, not how to run the tool.” Showing that he understands that there is an effort cost in utilizing and being an expert in a tool, which should not be required.

The other element of a modern release automation tool (assuming you are on the bandwagon of the container-driven pipeline), is the container-native status. Codeship and CodeFresh, two relatively new tools, are both hanging their hats on container-native applications, and assume you are running your application on containers and/or microservices.

Tapinfluence is one of a handful of paying Docker customers. And they are taking it one step further than most by Dockerizing their entire development environment. “In 30 minutes, someone could go from having nothing on their machine, to a full dev environment and ability to commit and deploy,” Robichaux explained, which is critical, as he not only has to support the core development team, but also data scientists who know how to code, but do not know the ins and outs of the application or how to create a build they can work against.

“Normally it would take three or four days of training to get someone up and running,” Robichaux said. Given the pace of the changing environment, he simply can not waste time getting new devs going.

Tapinfluence’s application runs on AWS, and it uses Convox to manage both its developer and production instances. As he said above the source repository is key, and Git is central to everything. Git is where all the vetted Docker Compose files are stored. The DevOps teams vet the core images, and developers manage the delta for the particular service they are working on. The net result is a unified delivery chain that can do a release within five minutes.

If I were to speak with Robichaux even a month from now, I would likely be shocked again at the amount of change his company has gone through. But, it is keeping an application up and running and delivering the results its customers expect.

In the true DevOps spirit, the goal should always be to push the needle toward faster, more frequent releases at a higher quality. If you stagnate with one stack, you will not be a DevOps environment by the end of the year.

August 4, 2016
Delivering DevOps’ Business Value

DevOps is an interesting space to be operating in right now. More than just culture or a set of tools and processes, DevOps delivers speed and agility that can be truly meaningful for the business. Unfortunately, for most large enterprises, the path to the benefits isn’t always well-known and isn’t assured.

Over the last five to 10 years, a number of DevOps tools and solutions have emerged: Puppet, Chef, Jenkins, Git, SaltStack, Elasticsearch … and the list keeps growing. Originally, these tools were sought by developers and system engineers for their ease of use and low cost of ownership: You could download it, use it the same day and solve your specific problem. The issue for enterprises, however, is that nature abhors a vacuum; the problem one developer addressed with Chef is being fixed with Puppet by another developer in a different business unit. Group A is using Jenkins, Group B is using Chef Delivery. In short, after five to 10 years of technology adoption by developers and system engineers, the tooling landscape in the DevOps space is packed to the rafters with competing technologies, all of which are solving similar problems with overlapping features.

So why should this matter to you at all? Without careful planning, consideration and execution, your business will derive little value from this DevOps exercise.

Here are a few common pitfalls we see far too often:

Too Many DevOps Tools Doing Too Few Things

Building Rube Goldberg devices looks neat on paper, but those mousetraps fail very often in real life. The more tooling and solution handoffs you have, the greater your likelihood of failure: the less likely you are to be able to scale horizontally or vertically, the more toolsets you need to maintain, and the more skills you need on your team. Convoluted messes do not yield speed and agility. If it feels wrong, it probably is. If it is overwrought, look to remove complexity from the landscape.

Reintroducing Risk and OpEx Spent on Menial Tasks

As an organization you’re onboarding risk, hidden costs and a lot of the things you just spent the last 10 years automating away: tribal knowledge, lack of governance, lack of compliance, lack of third-party auditability and reporting. Many enterprises spend millions of dollars making it so their admins and developers could spend time on more valuable workstreams, just to throw them back into the salt mines of making continuous integration (CI), continuous delivery (CD) and infrastructure-as-code “work” over umpteen toolsets. The goal isn’t for DevOps to “work”; the goals need to tie to some tangible (i.e. measurable) business benefits. Anything can be made to work, but far fewer IT programs deliver value. Be the people who deliver real value.

Taxation Without Representation

All of the stakeholders need a seat at the table. Whether that means forming a SWAT team from operations (all infrastructure domains and security), development, QA or a permanent DevOps matrix organization, all vested interests need a say in how the process and tooling develops for all impacted domains (which is just about everything) across all environments (i.e Dev, Test, QA, Production). Far too often we see one set of stakeholders acting as the service provider for another group of stakeholders playing the role of customer. This is a solution for and by Development and Operations.

Congratulations, you’re having a baby. Let’s make sure it’s not ugly, okay?

About the Author / Jesse Langhoff

Jesse Langhoff is co-founder and CEO of Raindance, a cloud and automation consultancy serving enterprises nationwide. With over 15 years of experience in leveraging technology to address business challenges, Jesse works with customers to determine the optimal path to meeting their goals through the use of automation and solutions provided by the leading vendors in the space. Areas of expertise include strategy and assessments, private/hybrid cloud services, process automation and orchestration, DevOps and operations as a service. Jesse holds an MBA from University of St. Thomas – Opus College of Business.

August 3, 2016
Jenkins World Speaker Gruver on the State of DevOps

Santa Clara, California, will be home to the biggest gathering of Jenkins users in the world Sept. 13-15. This year’s Jenkins World conference will feature Gary Gruver, DevOps expert and author of “Leading the Transformation.” We had a chance to connect with Gary and hear his thoughts on the state of DevOps, continuous delivery and what he thinks the biggest trends are.

devopsy.kinsta.cloud: As continuous delivery (CD) and DevOps continue to be adopted and advance, what specifically should we be on the lookout for?

Gruver: I believe the biggest opportunity for breakthroughs in CD and DevOps is in large, complex, tightly coupled systems. Most DevOps implementations have been with smaller teams—whether in small businesses or large businesses—that allow these small teams to work fairly independently. Currently, these are the fastest moving, most innovative DevOps implementations. That said, I feel the biggest opportunities for positive business impact are in the larger, more complex systems just because they are currently much less efficient. This is why I think we will see the biggest improvements in those environments, and innovations and updates will track towards these advancements.

devopsy.kinsta.cloud: How are technologies like containers becoming a bigger part of an automated pipeline?

Gruver: Containers make it easier and less complex to move to infrastructure-as-code, which is one of the big breakthroughs of DevOps. This space is moving quickly because of how important environment consistency is to companies. It will be interesting to see how this space evolves over the next few years.

devopsy.kinsta.cloud: What advice do you have for enterprises just starting their DevOps journey?

Gruver: Segment the applications down into different deployment pipelines to make the problem as small and less complex as possible. A deployment pipeline should include all the applications that have to be qualified and deployed together because of their architectural coupling. Then, optimize each deployment separately based on DevOps principles instead of forcing everyone to implement all the same DevOps rituals like was common with previous agile transformations. This is a topic I can spend quite a bit of time discussing and thinking about, as you can read more about in my book!

devopsy.kinsta.cloud: What roadblocks still exist for companies trying to adopt DevOps?

Gruver: Finding executives that are willing to engage with their organizations and lead the DevOps transformation is a solid roadblock. It is still new concept in larger enterprises that require the multiple acceptance from members of the C-suite.

devopsy.kinsta.cloud: What do you find most exciting about the current state of CD?

Gruver: It is finally scaling to large organizations where the majority of the code that is being worked with exists and therein are the biggest opportunities I see for improvement. This means that DevOps is being introduced right up the chain, extending it from just the realm of IT.

devopsy.kinsta.cloud: What do you want Jenkins World attendees to know about your keynote?

Gruver: I am planning to provide a framework you can use to help align your large organization on your DevOps journey. My objective is for DevOps practitioners in organizations of all sizes to walk away with tips for implementation and a better understanding of best practices to apply to individual DevOps journeys.

devopsy.kinsta.cloud: What does being “all-in” on DevOps mean to you?

Gruver: To me, being “all-in” on DevOps means that everyone one is committed to the DevOps principles and is working together to continually improve the development and delivery processes. In other words, they have the same approach to achieving the same goal.

devopsy.kinsta.cloud: Where do you think DevOps adoption is today?

Gruver: Mature in unicorns and just getting started in large enterprises; hence, there are so many opportunities!

To learn more about Gary Gruver and his approach to DevOps, please visit his homepage. While you’re at it, download a sample of his latest book, “Leading the Transformation.” Interested in learning more about Jenkins World or attending this year’s Jenkins World? Click here and register with the code JWDEVOPSCUST to receive a 20 percent discount.

July 29, 2016
The Disposable Development Environment
Wait! Just wait a dadgummed minute! It takes days to build a development environment, and now I am supposed to read an article on a disposable development environment?

Yes.

It seems like it took an entire sprint to upgrade PHP! Now I am supposed to let them build something so they can trash it?

Yes … yes, you are.

Disposable DevOps Thinking

DevOps is based on five pillars:
- Culture
- Automation
- Lean Thinking
- Measurement
- Sharing
Because we automate environments such that they are easy to share, we should be able to measure meaningful business impact. This model is a DevOps practice of modeling developer workflow for operational tasks.

Why a Disposable Development Environment

Log in to your workstation and delete the runtime for Java, PHP, etc. Remove, or change, a few config files and empty the trash. Now what? What if your entire team did this because they had a great idea? Panicking yet? What if getting started in any team was as easy as:
- Cloning the project from source control
- Starting the runtime environment
- Obtaining caffeine
- Getting to work
The majority of developers today have a hand-built, artisanal, bespoke workstation setups with the following characteristics:
- It takes days to onboard a new team member.
- Innovation around runtime environments is stifled.
- Moving from one team to another is the work of days.
- Workflow is more like Ops instead of Dev.
Let’s set some goals:
- No more than 30 minutes for a new team member to make their first code commit.
- No more than five minutes to throw away an environment and start over.
- No more than five minutes for a developer to move from one team to another.
- Runtime changes happen the same way as application changes.
None of this is possible unless your teams can throw away a runtime environment at will, thus disposability is an “[-ility]” that we should expect to be delivered with our software.

Disposable is Indispensable

The most important concept is handling runtime of the application with a virtual machine (VM) on the workstation. The application code remains on the workstation. This means that developers still use all the tools and workflows they have today. If a mistake happens on the VM, kill it and start over. If it happens on the workstation, then its time to rebuild the laptop.

At its core, the ideas borrows from common concepts in our production environment (and a specific tool example):
- Hypervisor for supporting guest virtual machines on the workstation, such as Virtualbox
- Provisioner to configure the guest machine, such as Chef
- Source Control to track and manage changes to the application and the configuration, such as git
- Glue so the provider and provisioner can be expressed as code and managed through source control, such as Vagrant
Onboarding a New Team Member

Have the new employee follow a set of directions. It should take no more than 30 minutes for the employee to install the tools and the application he or she is to work on. As a manager, this must be measured and tested relentlessly. New hires should be directed to keep notes on trouble spots and anything that takes a long time. They improve the documentation for the next new hire.

Accelerate Innovation

Developers say, “I wish I could upgrade to PHP X! I would be done in minutes, not days!”

Developers are capable of such an upgrade, so the real problems are:
- It takes a few hours to upgrade a language version.
- If the attempt fails, it could be longer to unravel all the hand-rolled changes.
- If the attempt succeeds, everyone on the team is committed to undertake a fraught journey to upgrade their bespoke workstation.
With management asking about things such as feature velocity, time to value and internal hurdle rates, who is willing to take that sort of time only to succeed and cause everyone else on the team grief, too? This is why security upgrades are always done with such pain. They are delayed because they are “non-functional.”

Now abstract the runtime to a VM and the configuration of the VM to code. Assume the developer wants to upgrade PHP.
- Developer destroys the current VM with PHP 5.2.6 on it.
- Developer goes into the Chef code (for example) and changes the PHP version to 5.3.29.
- Developer launches a new VM with a single command.
- Developer runs automated tests.
The most likely outcome is some tests fail. With a bespoke environment, this is where the upgrade effort stops. Fixing all the tests is a commitment to getting the entire team to move in lock-step. On a team of just five people this is daunting. Developers are not project managers.

With a disposable development environment, it takes five minutes to make the change. Developers know it is an identical effort for their colleagues, so the thinking changes.

Given an arbitrary time window, the tests are fixed and the PHP upgrade saves the time or improves system performance or patches a security hole. To share this change across the team this same developer commits the change in the Chef code. They push it to the code repository and message the team, “Hey PHP 5.3.29 works, please adjust.” One person does all the work.

Team members stop what they are doing. They stash the work they have inflight. They pull the changes from the code repository. They start the VM and Chef configures it. They unstash their work and get back to providing business value. In less than five minutes the entire team is done.

Accelerate Security and Compliance

What if a developer’s upgrade causes security issues? Changing something as important as the language version is meant to illustrate this power. But this is not the right question to ask. Instead, ask this one, “How do we ensure we are secure before we get to production?”

Assume that any change in the development environment is reflected in production through the same process. For example, when code is deployed to quality assurance (QA), the Chef cookbooks run and they bring up the machine with the new PHP version. Why would there not be tests to show that the application is at least as secure as previously?

Even more to the point: By making it easy to upgrade the base language, test the change and share it across the team, upgrades are much less risky.

This thinking has some new assumptions:
- You trust test automation at the application level. (common)
- You trust the test automation at the infrastructure level. (uncommon)
- You have automated security and compliance practices that check before a production release. (rare)
As managers we must help our:
- Ops team becomes better at the practices of code management since the infrastructure will be code.
- Development team makes responsible changes in concert with operations, security and compliance groups.
- Security teams adopt a security-as-code mindset to facilitate testing before promotion from development.
- Compliance team joins the development effort so changes are already part of audit output. Compliance-as-code is already on the way.
Business Outcomes of a Disposable Development Environment

We hire new people when we need them. Taking two weeks just to get into a working state means we are delaying time to value. Delaying 30 minutes is less time than filling out the HR paperwork. We need this critical time to fill the need that caused the hire.

Developers have more freedom in the infrastructure to try their ideas. The also have the safety net of putting it back like it was in less than five minutes when the idea does not pan out.

Patches to the runtime environment for security can be applied at development time where they can be tested through the full deployment cycle. This takes minutes instead of days.

If all teams are using a standard method and tool chain, then it is possible to adhere to the maxim, “Put your best people on your biggest opportunity.” Developers can move from Team A to Team B in less than five minutes and get started learning the code. They can move back in the same five minutes.

Changes in the runtime happen at development time, and they are promoted and release with the application. So, perhaps most of all, if it works on the developers laptop then it will work in production.

Without the ability to simply throw away the environment and easily start over, Dev and Ops cannot innovate toward these benefits. So go ahead and dispose of those bespoke workstations, and be sure to manage toward the benefits:
- No more than 30 minutes for a new team member to make their first code commit.
- No more than five minutes to throw away an environment and start over.
- No more than five minutes for a developer to move from one team to another.
- Runtime changes happen the same way as application changes.
July 26, 2016