Tag: devops

  • DevSecOps: Where DevOps and Security Meet

    DevSecOps: Where DevOps and Security Meet

    Catching up with three IT leaders on the role of security in the changing world of DevOps

    The DevOps methodology as a software and engineering culture goes back nearly 10 years—Patrick Debois coined the term when he named a Belgian software conference “devopsdays.” Since then, the movement has taken on a mind of its own, turning into the go-to strategy for enterprises the world over aiming to accelerate their development timelines and deliver better products faster.

    In the shifts and changes that have happened over the last decade, one has been the idea of “DevSecOps,” or the intersection where security practices and DevOps transformations meet. Recently, at the DevOps Enterprise Summit 2018 (DOES18) event in London, several key players in the DevOps world sat down to take a deep dive into the world of DevSecOps. In the following article, we’ll review some of the key points discussed by Ilkka Turunen, head of Solutions Architecture at Sonatype; Zane Lackey, founder of Signal Sciences; and Margo Cronin, senior solution architect for Amazon Web Services during our panel discussion at DOES18.

    The first point of the discussion centered around the role of security in DevOps, and how the name “DevSecOps” should never make you think security is secondary.

    “I’ve never been crazy about the term DevSecOps, because it’s like ‘Sec’ is an afterthought,” said Turunen. “You know, we were squeezing it in between Dev and Ops, the last kid that got on the bus, and we’re like, go on, just sit in there. For all of us, security is the first priority, the top job—’job zero,’ we sometimes call it. And therefore, for DevOps, it actually understands that security is key, and is the first thing that you do.”

    Turunen pointed to recent changes brought on by GDPR that have made privacy one of the pillars of software development, and how this has brought about further emphasis on security in DevOps transformations. In this new world of GDPR regulations, it’s not limited to just data portability and data breech notifications, but truly goes into “privacy by design.” As such, security is paramount.

    Later, the conversation turned to the idea of how one can create a culture where everyone thinks of themselves as a security practitioner, a seemingly necessary step to having foolproof security practices. The answer lies in creating an organization where security is part of the fundamental culture—a similar cultural change as to what happened around testing.

    “So if you think about testing 10 years ago, it was literally people running from test execution plans, and gradually they changed from that to becoming writers of tests, people that write the automatic-execution, help people, help the floor become more efficient at testing for themselves,” said Turunen. “Teaching them unit testing, all these other frameworks. So I feel like we’re at the brink of a similar kind of change. I think it’s a mixture of both incentives and psychology, and just changing roles.”

    Lackey puts it even more simply—that good engineering just goes hand in hand with good security.

    “The best way I’ve ever seen, like the highest performing organizations view it, is security is a subset of good engineering. In the way that resiliency is, reliability is, quality is, performance is, is a subset of good engineering,” said Lackey.

    Finally, the conversation turned to the role of public cloud service providers and how they can help uplift security for software organizations. For Cronin, the idea of machine learning holds a lot of promise for increasing security.

    “You now have services that can scan your landscape and say do you know these large files contain client identifying data, do you know you have keys there?” said Cronin. “And then you have services where you can then change that behavior automatically. But I think that’s where we’re going to see cloud service providers become a lot more active. You know, using machine learning to harden your production landscape before you actually even go to the security operators.”

    While the world of DevOps is constantly evolving, growth in highly regulated and compliance-oriented industries—coupled with increased global concern over data privacy—have put increased emphasis on incorporating security throughout the software pipeline. To learn more about how these DevOps experts view DevSecOps, and how they are making security a bigger focus in their organizations, you can watch the entire discussion on DevOps TV.

    Bonus: You can also watch Cronin’s DOES18 presentation on “Security Automation at Scale” and Lackey’s presentation on “How You Can Use DevOps to Make You More Secure.”

    And be sure to join us next time at DevOps Enterprise Summit Las Vegas, Oct. 22-24, 2018!

    — Alan Shimel

  • How to Use APM to Hold Cloud Providers Accountable

    How to Use APM to Hold Cloud Providers Accountable

    Here’s the challenge: Cloud providers’ service level agreements (SLAs) typically stop at the edge of their cloud, while your internal service level expectations run end to end. Measuring performance from the end user to the application and back, including device details, user productivity and page load times, is essential for customer satisfaction and continuous performance tuning. How long does it take to launch an online app, open a work order or complete a claim form? What are execution and completion rates in different locations? The metrics and associated metadata provided by application performance monitoring (APM) tools can help your DevOps teams rapidly identify actual performance issues, troubleshoot them quickly and efficiently and optimize cloud spend and service level agreements.

    Automate Data Collection

    Collecting performance details for multiple web browsers, operating systems and devices is impossible if you have to manually tag and instrument the code. Modern APM solutions automatically deploy JavaScript snippets, page tags or agents to your web pages, Java and .NET applications and mobile apps. Small binary agents and efficient compression algorithms ensure minimal performance impact to the end user device or the network as they send telemetry information to the APM back end. Your DevOps team can then work with the actual attributes of every device, including manufacturer, model, operating system type and version and resource consumption to monitor the end user experience across IaaS, PaaS, SaaS and hybrid environments.

    Early Warnings with APM

    To trigger early warnings, APM systems automatically determine an application baseline, or you can manually set specific thresholds. Typically, internal thresholds are set up to provide early warnings of possible issues before users are negatively impacted, while external thresholds can be linked to your actual SLA terms.

    These SLA reports are more than colorful views. By using dashboards that color-code SLA status based on the end user experience, you can better enforce service levels with your cloud providers. For triage purposes, you can break out details by department, geography, operating system, device type, target server, carrier and other characteristics as needed. You can also see at a glance your compliance measurements, which show the percentage of response times that are meeting the agreed-upon targets with your cloud providers to hold them accountable for performance.

    Streamlining Remediation

    Automation is key to accelerating mean time to repair (MTTR). When an alert is triggered, APM tools integrate with your service desk systems to automatically open trouble tickets, identify probable causes and analyze the business impact for prioritization. This level of detail and integration significantly reduces delays that are historically associated with performance troubleshooting, as it provides the necessary context for troubleshooting. Another option with advanced APM solutions is the ability to automate remediation of common end user experience issues, without involvement of the service desk staff.

    Comparing Before and After

    Another useful outcome of these detailed metrics is the ability to compare parameters before and after a change. By baselining performance, APM tools help you document and validate the actual end user experience impact of code releases, device changes or service provider upgrades. It’s not uncommon for users to complain after a new release, but using APM reports you can take a data-driven approach to quickly investigate user complaints by comparing different time intervals. You can start by exploring various characteristics and isolate the affected group based on device health, network subnet, geography, server or cloud provider. Once you have determined whether the problem is within your control (code, architecture, etc.) or within your service providers’, you then can have more productive discussions with service providers to demonstrate exactly where and when an SLA violation occurred.

    Keeping Track of SaaS Applications

    As you expand use of SaaS applications such as Office 365, end user experience monitoring and SLA management can be used to hold these providers accountable. Slow application launches, logins, page loads and other performance issues can impact user productivity, adoption rates and deployment schedules, costing the organization support resources and unused license fees. That’s why SaaS-based APM tools give you immediate usage measurements, enabling you to quickly adjust license quantities and optimize costs. Real-time monitoring of user wait times, crashes, device health and other experience metrics gives your team comprehensive awareness of how performance, device type or operating system versions are affecting employee productivity. This information can be used to quickly identify problem areas, validate migration plans and prioritize future investments.

    Monitoring for Accountability

    Getting what you pay for from your cloud providers is much easier if you incorporate detailed user experience measurements into your SLAs. A best practice is to monitor everything that happens on every device across the organization such as how long it takes to boot up, login, open specified apps and perform business-critical tasks. If any of these are off target, your APM solution can open and prioritize a trouble ticket with a list of probable causes, before the affected users can call support. Automated end user experience monitoring, reporting, and policy management, backed by self-instrumenting devices and apps, are essential links between a service provider’s commitment and your actual results.

    — Gayle Levin

  • How to Convince Your Manager to Send You to DevOps World | Jenkins World 2018

    How to Convince Your Manager to Send You to DevOps World | Jenkins World 2018

    The largest gathering of Jenkins users and DevOps practitioners is less than a month away. DevOps World | Jenkins World 2018 will be held in two locations this year, Sept. 16-19 in San Francisco and Oct. 22-25 in Nice, France. With exciting keynotes from industry influencers including Dr. Nicole Forsgren, CEO and chief data scientist at DORA, and James Governor, analyst and co-founder of RedMonk, there will be tons of learning and networking opportunities. There will even be a “Westworld” themed party, making it an event you do not want to miss.

    So now that we’ve convinced you to attend, you need to convince your manager why they should send you to DevOps World | Jenkins World 2018. Don’t worry: There are lots of good reasons why attending would be beneficial to you and your company. Once you have successfully convinced your manager to attend DevOps World | Jenkins World, don’t forget to register! To sweeten the deal, you can enter the promotional code just for DevOps.com readers: JWDEVOPSCUST. That code gets you 20 percent off your registration.

    Keep Learning

    With more than 70 sessions offered in San Francisco and 50 sessions in Nice, all presented by DevOps and Jenkins experts, DevOps World | Jenkins World provides a chance to learn from DevOps leaders. Be sure to emphasize to your manager the importance of learning from the very best in the DevOps community, in training and workshops and, of course, in the breakout sessions. From Jenkins founder Kohsuke Kawaguchi to CloudBees CEO Sacha Labourey and the aforementioned industry influencers, your manager will greatly appreciate the knowledge you bring back to the office from experienced industry experts.

    You should definitely take advantage of some outstanding training opportunities to enhance your continuous delivery, Jenkins and DevOps knowledge. Available training sessions include Jenkins Certification Training, Jenkins Fundamentals, DevOps Leader Certification Training, CloudBees Core Fundamentals, CloudBees Core on Kubernetes and Value Stream Mapping for DevOps. Additionally, you will receive a free Jenkins exam with the purchase of a full conference registration. That is a huge value-add for both your resume and your organization!

    Build Your Network

    DevOps World | Jenkins World brings together thousands of software development experts, thus providing numerous networking opportunities. The conference gives you the opportunity to learn of challenges other organizations in the industry have faced and how they’ve overcome them. If they have already solved a challenge you are just starting to tackle, you could walk away with knowledge that more than pays for the cost of the conference. Conference attendees can also share success stories that may inspire your organization’s next big win. Make it known to your manager that you will be exposed to people like you, who have similar business needs and challenges, whom you will be able to connect with and learn from.

    Invest in Your (and Your Company’s) Future

    As we previously mentioned, with the industry continuing to innovate and evolve, having the skill set to keep up with these changes help make you a valuable asset to your team. When convincing your manager to let you attend, make sure you also present how this knowledge will help push you and your team forward, ultimately propelling your entire organization forward. Highlighting the potential ROI of this opportunity will help your manager better justify the cost to send you to DevOps World | Jenkins World. Detail exactly how much airfare and lodging will cost, but also note what kind of impact it will have on the organization’s bottom line. The ROI will be evident—make that clear!

    We would like to think we have provided some pretty solid justifications for you, but if you still need an extra boost, we have also created an email template to use when sending all this over to your manager for review. Once your boss gives you the green light, go register!

    — Alan Shimel

  • VMware Extends DevOps Reach via SaaS Apps

    VMware Extends DevOps Reach via SaaS Apps

    VMware, at the VMworld 2018 conference today, announced it will be delving deeper in the realm of DevOps with the launch of a continuous delivery pipeline dubbed Code Stream.

    In addition, VMware announced Cloud Assembly, a set of declarative tools that enable IT organizations to spin up a cloud in as little as 10 minutes by managing infrastructure as code, and Service Broker, a catalog through which services residing on multiple clouds can be published, governed and secured.

    Milin Desai, vice president and general manager for the Cloud Services Business Unit of VMware, said these offerings extend the reach of VMware’s Cloud Automation Services that are all invoked as software-as-a-service (SaaS) applications.

    VMware also today announced a beta release of Secure State, a set of tools for tracking security alerts across Amazon Web Services (AWS) and Microsoft Azure that also can be used to investigate when changes to those environments were made. Secure Slate is based on the technology the company gained by acquiring CloudCoreo earlier this year. What’s more, VMware is updating the Wavefront by VMware monitoring service to add support for deeper support for containerized workloads running on Pivotal Kubernetes Service (PKS). Wavefront also now supports the Amazon Lambda serverless computing framework made available by Amazon Web Services (AWS).

    Code Stream is designed to track code across multiple platforms and comes with pre-built plug-ins for Wavefront, Harbor, Nexus, Pivotal Kubernetes Service (PKS), Ansible and Slack. VMware is also committed to providing integrations with continuous integration/continuous deployment (CI/CD) platforms such as Jenkins, Desai said.

    VMware has previously made extensive investments in software-defined data centers (SDDCs) based on a layer of management software deployed on top of VMware vSphere. As part of that effort, VMware today announced version 6.7 of VMware vSphere, which adds tools for verifying the state of a virtual machine, and a new Platinum edition of the platform that includes VMware AppDefense, to secure application workloads running on VMware vSphere.

    Beyond the virtual machine level, the scope of VMware’s DevOps portfolio has been limited. By adding a range of DevOps tools that are made available as SaaS applications, VMware now can provide tools spanning just about everything, from cloud orchestration to code delivery, Desai said.

    The expanded push into DevOps comes at a time when VMware is also extending the scope of its alliance with AWS. The company earlier this week announced it has lowered the cost of entry of VMware for AWS by 50 percent for a limited time and is making available a three-node configuration option. Previously, VMware required customers to set up a minimum four-node configuration. VMware will enable IT organizations to configure a three-host software-defined data center (SDDC) for the cost of two hosts.

    The company is further helping to reduce costs by make it possible for IT organizations to also specify the number of processor core counts for Oracle and Microsoft applications running on AWS, along with new options for deploying NSX network virtualization software.

    It’s unclear to what degree VMware will be able to leverage its historic strengths in server virtualization to become a significant force in the realm of DevOps. The acquisition of Wavefront in last year was clearly a significant step in that direction. But the individuals with an IT organization who decide what virtual machines to employ are not necessarily the same individuals selecting DevOps tools. VMware is clearly hoping that as more IT organizations embrace DevOps processes spanning multiple clouds, many more of them will view the company’s growing portfolio of SaaS applications as a natural extension.

    — Mike Vizard

  • When DevOps and ITSM Collide: Mistakes to Avoid

    When DevOps and ITSM Collide: Mistakes to Avoid

    In many ways the DevOps movement evolved as a reaction against the worst elements of IT service management (ITSM). IT leaders wanted to get from under the yoke of overly complex processes, bureaucracy and red tape to speed up software delivery, and to just get stuff done. Now that DevOps has kicked into full gear at so many organizations, the question remains: What do we do about ITSM?

    While the instinct in some may be to completely ditch ITSM or to just let the ITSM team operate in a separate orbit from DevOps practitioners, experts say that would be a big mistake.

    “DevOps aims to deliver high-quality software to the business faster and in shorter cycles,” explained Krishna Mohan Reddy, vice president and deputy global head of Cognitive Business Operations at Tata Consultancy Services. “However, it still does not eliminate the need for controls.”

    In many ways ITSM is the yin to DevOps’ yang—the two operating philosophies do offer contrasting viewpoints but when the operate in a single system they can be extremely complementary and synergistic.

    “Maintaining the proper balance between the ITSM and DevOps helps the organizations to scale and grow and become more organized,” said Sachin Agarwal, DevOps engineer and solution architect for Mantra Labs. Operating at DevOps speeds with ITSM frameworks in place keeps finger-pointing at a minimum and reduces the risks of failed deployments. “Both in harmony will increase the efficiency and reduce the blame-game within the organization.”

    As organizations try to figure out how to achieve that harmony, here are some pitfalls they should seek to avoid:

    Letting Each Tribe’s Preconceived Notions Hold Back Overall IT Progress

    It can be easy to get wrapped up into dogmatic fervor that your particular philosophy is the One True Path for IT success, but that really does nobody any favor. Organizations that want to pick up the best of both ITSM and DevOps need to encourage stakeholders to approach the table with an open mind.

    “You need to compromise. A lot of the new, young practitioners in DevOps and Agile will pretty much automatically discount opinions coming from people who have got ITIL certifications,” said Andi Mann, chief technology advocate for Splunk. “And vice versa—a lot of traditional operations and development teams will look at the people in DevOps and Agile and think they’re all cowboys. But they all have something to learn from each other.”

    For DevOps practitioners, it’s important to keep in mind that ITSM controls such as service requests, change management or structured management of incidents and problems don’t have to stop a team from delivering quality software at speed, said Troy Vetter, COO of Coda Global.

    “In fact, speed and quality are actually helped by being closely monitored. In IT, just like in science, if it isn’t seen, measured, and “reproducible, it doesn’t really count,” he noted. “So, ITSM is actually the perfect complement to DevOps because it aids in the visibility, measurement and reproducibility of key DevOps processes.”

    Failing to Address the Elephant in the Room: Change Management

    Analyst Roy Atkinson agrees that ITSM has a lot to bring to the table for DevOps workflows. ITSM’s rich history in thinking about and tracking operational best practices offers tons of value in improving the customer experience with the software being delivered. But on the flip side, ITSM teams can’t continue to operate as they did in the past. They need to compromise and learn new ways of accommodating DevOps approaches—particularly in the area of change management.

    “Change management has often been where DevOps and ITSM collide,” said Atkinson, who analyzes the service management market for HDI. “The stereotypical Change Advisory Board must radically revise its approach to be in sync with the enormous amount of change that DevOps can produce in a day.”

    The good news is that thought leaders in the ITSM world have been thinking hard about this issue and have been evolving practices so they can embed change management controls into a DevOps framework without holding back continuous delivery.

    “There is some excellent recent thinking in the ITSM world about how change management can serve its intended purpose without being a roadblock by acting as an enabler of change and being involved all along the way, rather than a bolt-on quality check at the end of the line before the production environment,” Atkinson said.

    Maintaining Separate Toolchains

    Often times one of the big reasons ITSM will remain a roadblock for DevOps isn’t because the ITSM folks aren’t willing to collaborate, but simply because each team relies on completely separate toolchains.

    “You might have a tool that developers use for tracking bugs or product backlog and then there’s a completely separate IT service management tool,” said Donna Knapp, curriculum development manager for ITSM Academy and author of the DevOps Institute’s course on ITSM for DevOps. “So what you end up doing is forcing developers to use some process that’s outside of their norm in order to address issues.”

    As Vetter explained, a lot of the knee-jerk DevOps reaction against ITSM has to do with an aversion to the historical view of ITSM requiring manual inputs in monolithic ticketing systems. But the technology of ITSM controls has advanced—it just needs to be appropriately implemented.

    “Self-service requests, automation flows and IT orchestration are now our front door to actions, and IT service management can and should be happening in the background, automagically created, maintained and measured by our DevOps tools,” he said.

    — Ericka Chickowski

  • DevOps and Systems Thinking: The Farmer, His Tractor and Olive Garden

    DevOps and Systems Thinking: The Farmer, His Tractor and Olive Garden

    As a DevOps and Agile consultant, I work with many technology leaders who see DevOps as this big tangled mess of which they are trying to make sense. When I talk to them, I have to teach them to lead in a systems-thinking manner, a key tenet of DevOps. Making sense of systems thinking is no easy task, but to make it a little simpler, let’s tell a tale of farm-to-table that includes the characters of tractor, farmer and popular Italian restaurant Olive Garden.

    A tractor is at the very most multi-purpose—it can till the field, spread fertilizer, pull a trailer to return a harvest, etc. The farmer, on the other hand, might be interested in things such as the acidity of the soil, water levels and local weather forecasts, but his ultimate goal is singular (to produce a yield of crops) and his domain expertise is narrow.

    Let’s say this particular farm provides tomatoes to Olive Garden. Olive Garden views the relationship between farmer and tractor from a completely different perspective. It cares about purchasing tomatoes to add in a variety of dishes, and cares much more about getting the tomatoes delivered to the store than how those ingredients were produced. After these tomatoes leave the farm, they become part of a complex process of delivering quality ingredients to the plates of customers.

    Now that the picture has been painted, let’s pretend that the farmer is really a member of the development team, the tractor is Jenkins, and Olive Garden represents the leadership team or their business priorities. The farmer, or developer, is thinking very narrowly and tactically. Jenkins, or the tractor, can’t prove the farmer is moving business value from one end to the other. Contrastingly, leadership wants to see everything done in a holistic way, connected to metrics and business value. This scenario leaves farmers and Olive Garden working in silos and thinking differently about how to reach goals. Sound familiar?

    This is where systems thinking, or holistic thinking, can help unite leadership and technical teams, improving culture, customer satisfaction and more. So, how do we get from this blasé transaction of tomatoes to table (or code to customer)? In general, if we only focus tactically on what we’re trying to accomplish, we aren’t thinking holistically. Holistic thinking means looking at the entire delivery toolchain and how a single piece of code ultimately will affect the end user or customer.

    The goal of leadership is to try to drive vision and to make decisions based on real data. Developers need to try to prove to leadership, especially when they start talking about tools, automation or cultural changes, that there’s going to be value in those initiatives. Sounds easy enough, but sometimes leadership doesn’t provide a good vision for how they want developers to think outside of the box, and so, they’re stuck. We’ve seen this picture before. We have DevOps engineers that are just another silo in the process; not intentionally, but because leadership doesn’t set a good vision. Systems thinking isn’t in place.

    As a consultant for Agile teams, I often see Agile and DevOps mixed together. And what I don’t agree with is that the intersection point is small; that’s a common misconception. But when we want to think outside of the box, we need to focus on ideas and capabilities and we need to be able to make data-driven decisions.

    So, what is the intersection of Agile and DevOps? Agile is just a component of DevOps. DevOps is the extension of Lean and other methodologies that came before it. In other words, Agile and DevOps can’t live without each other. In organizations that are trying to do both, I’m coaching them to try to utilize both frameworks and both cultures to do what they need because they’re ultimately the same.

    Providing a taste of data-driven DevOps to leaders is how to get them to turn their head in the direction that you want it to go.

    Ultimately, systems thinking breeds continuous improvement because, if you have a holistic view, you’re monitoring all parts of your process, and so you can have more meaningful retrospectives and you’re thinking about what you can improve all along the way. And you’re on a journey to make your organization, or your team or yourself, epic.

    — Logan Daigle

  • The Struggles DevOps Administrators are Up Against

    The Struggles DevOps Administrators are Up Against

    DevOps has quickly gone from being a niche concept to a widespread practice that is gaining traction rapidly in both large and small organizations. As it becomes a key part of many development teams, administrators must work to integrate DevOps techniques, tools and practices into a wide range of teams, from operations to development, support and management.

    The seamless completion of this implementation, together with the overall change in methodology and culture from top to bottom, provides a smoother workflow. The issue, however, is that admins are being asked to do more with less. DevOps administrators from large companies are struggling to keep pace, partly due to the newness of the practices, and in part out of a need to provide a competitive advantage for the business. Additionally, they find themselves in the middle of many different cultural pressures. All of this is leading to problems in fully implementing and reaping the benefits of a fine-tuned DevOps machine.

    That said, working through the implementation of a DevOps techniques will be worth it in the end and to make the transition easier, here are some specific pitfalls that administrators should try to avoid.

    Reliance on DevOps Technology

    One burden that is often faced by DevOps admins is an organization’s over-reliance on technology. In theory, technology is the easy part, but too often organizations become enamored with the newest shiny automation tool and find themselves in a cul-de-sac of isolation, forgetting to bring the rest of their organization with them.

    The wave of digital transformation that many organizations are experiencing can present additional difficulties as new technology is being implemented throughout different business units and administrators find themselves in high demand.

    Automation is awesome, but it isn’t the answer—it’s part of the recipe. The solution requires attention to processes and culture. According to a Gartner study, 73 percent of what organizations should focus on consists of attention to culture and communication, information exchanges and building operations process and organizational consistency. Only 27 percent should be on tooling.

    As the growing emphasis on DevOps places an added burden on infrastructure teams already struggling to cope with the digital transformation in their organizations, unification will be key to success. Ignoring the importance of creating a harmonious culture that embraces DevOps and processes that foster the methodology can be costly. Ensuring that tools are utilized in a smart way alongside people and processes will ultimately lead to more success.

    Building Collaboration Between Dev and Ops

    DevOps trust and transparency is at the core of release management. This level of collaboration and trust ensures that both sides of the equation agree when it comes time to ship software.

    Both sides in Dev and Ops frequently misunderstand the other’s motivations around production control and release management. Stability is king for Ops, and they would love nothing more than preserving uptime in each release, even if it means a blockage of imperative software updates. Dev, on the other hand, wants to move quickly, and they often make assumptions about what is required to support software in production. To help unite the two requires administrators have the ability to fill in the information gap that exists between Dev and Ops.

    In a way, DevOps admins work as the therapist for a severed relationship between Dev and Ops. Bridging the divide between these two departments can, at times, feel like counseling an organization to communicate better. But doing so through integration and collaboration is a surefire way to make life easier for everyone involved. DevOps doesn’t force people to become who they’re not; instead, it promotes cooperation, tolerance and shared responsibilities between the teams. 

    Lack of Transparency

    What many administrators also lack is a way to clearly understand, prioritize and utilize the data they have. From an agile practice perspective, that level of visibility should be established early on in a data reporting structure—project, initiative, etc.—and with the proper software solution. A solution that combines application release, environment, quality and deployment data across the portfolio to drive continuous improvement of software delivery.

    Being able to utilize this data makes a world of difference for delivery teams to be able to quantify, correlate and predict outcomes to help solve problems and make better decisions. The most basic, yet beneficial, insight you can have when making these decisions for an organization is to have the transparency to know that what you are doing is working.

    Creating a Culture vs. Working in Silos

    Application release delays costing hundreds of millions of dollars can be caused by poor management of complex enterprise software releases. A big part of the issue is that the very nature of agile and DevOps is to work in smaller teams, which can naturally create silos. For a given release, there can be many teams and, in some cases such as test environments, teams from different projects can collide due to lack of oversight. This complexity presents significant management problems and, without insights across the entire process, release trains are bound to crash.

    A culture of working in small teams on a single release lends itself to working in silos, and that isolationism often conspires against organizationwide success. This construct needs to be broken, as it produces an additional level of complexity and unification that will be a key point of emphasis for organizations in their road to digital transformation success.

    This unification will be especially important in large organizations that see frequent changes to their software release cycles, sometimes daily. It is imperative for these organizations to avoid silos and favor better communication with pronounced team roles, especially with the added confusion that the rapidly evolving delivery cycle can bring.

    Creating a cohesive and harmonious DevOps culture will benefit everyone in an organization in the long run. To be successful at this, though, it’s imperative that DevOps admins are given the rein to institute the change that they see fit. Admins must educate themselves on the latest technology, learn how to use and monitor it and bring in the rest of the teams so everyone can work together. But the burdens they are up against need to be dealt with on an organizational level from the top down, creating the ultimate DevOps working environment for all.

    — Bob Davis

  • Important DevOps Roles Every Organization Needs to Succeed

    Important DevOps Roles Every Organization Needs to Succeed

    There is no agreement between the scholars and the practitioners of what the DevOps concept necessitates. There are many definitions available for the term “DevOps,” but it is the term used for emphasizing the collaboration between operations and development.

    Development (Dev): This is a process for creating a software product consisting of interrelated activities of software requirements, analysis, coding, architectural design, integration, testing and acceptance testing.

    Operations (Ops): This is a process of putting into use, and supporting end users in the use of, software product in the operational environment. Its activities include upgrade, installation, operation control, migration, configuration management, monitoring, alerting, support and availability.

    DevOps Roles Required for an Organization

    Many IT organizations are looking to embrace DevOps to increase their pace of software development and realize the business agility that stems from accelerating and streamlining the communications between operations and development.

    However, there is no fast or simple way to achieve DevOps. Many organizations have approached it as a pure technology play, but the successful path begins with the best people in the right DevOps roles with the right DevOps skills and an interest to collaborate.

    Experts in IT need to empower and employ evolving professional roles. Working as a lead change agent to supervise the transition, these DevOps roles include automation architects, security engineers, release managers, experience assurance experts, developer-testers and utility technology players who understand operations and development.

    DevOps Evangelist

    This individual needs to promote the benefits of DevOps by quantifying and identifying the business benefits that come from the higher agility that DevOps delivers. Reporting as a change agent, the DevOps evangelist ensures buy-in from operational and development teams, recognizes the important roles to handle DevOps delivery methods and ensures IT professionals are empowered and trained to make those changes.

    Release Manager

    The release manager is responsible for addressing the coordination and management of the product from development through production. Primarily they work largely on technical details and obstacles project managers are not involved with. Release managers supervise the integration, coordination, development, testing and deployment to support continuous delivery.

    Automation Architect

    The role of automation architect becomes important in DevOps, as this technology depends largely on automated systems. They are responsible for designing, analyzing and executing strategies for persistent integration while conforming high availability on pre-production and production systems.

    Software Developer/Tester

    The heart of the DevOps organization is the role of a software developer. Under this technology, the title of a software developer will stay the same, but the job of a tester/developer slowly raises the scope of responsibilities. These developers are not only responsible to convert new requirements into code, but also deploy, unit test and handle the ongoing monitoring.

    Experience Assurance Professional

    While the quality assurance function is frequently part of the software development, a new type of control becomes necessary when organizations adopt DevOps. The need for QA testers is being replaced with a need for XA experts charged with making sure that new functions are launched with the end user experience in mind.

    Security Engineer

    Considering the conventional waterfall development, system security is immensely an afterthought. It is a nonfunctional condition that, such as QA, is frequently tacked on toward the end of the system development. DevOps-minded stores have security engineers working side by side with programmers, incorporating their recommendations much earlier on in the process.

    Utility Technology Player

    Traditional IT operations or systems management professionals concentrate on maintaining the servers running. The primary cause of service interruption is likely to be the applications being run on these servers, so the administrators introduce very strict controls on what’s allowed to operate on their servers. They need extensive QA in a staging environment, large transfer and operations documentation and very rare issues. Traditional programmers have been heads down-coders without any involvement in post production systems.

    Conclusion

    A successful DevOps implementation is one that begins with the best people in the right DevOps roles to address all aspects and promote the speed and agility afforded by DevOps.

    — Saikumar Talari

  • DevOps Chat: The Impact of Automation on DevOps and Society, with Bob Reselman

    DevOps Chat: The Impact of Automation on DevOps and Society, with Bob Reselman

    Those of you who have been reading DevOps.com for a few years are familiar with the RoelBob cartoons, which have a prominent spot on the home page. RoelBob’s creator, Bob Reselman, is also a technologist and creator of other forms of media. Lately, he’s been writing a series of articles about the impact of automation on society as a whole—not just DevOps.

    Bob is a really smart guy and a great interview, as well. Even if you don’t agree with this thoughts on automation, it’s worth giving what he says a listen.

    As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

    Alan Shimel: Hey, everyone, it’s Alan Shimel, and you’re listening to another DevOps Chat. Got a really great DevOps Chat for y’all today. I’m joined by a good friend of mine, a frequent contributor, one of the team at DevOps.com—none other than Bob Reselman, creator of the RoelBob cartoons, Bright Ideas TV, the creative force and brains behind Shimmy Tunes, as well as a writer in his own right, not only at DevOps.com, but at a lot of the leading tech companies out there today.

    So, Bob—welcome!

    Bob Reselman: Oh, thanks for having me, Alan.

    Shimel: You know, I hope I didn’t embarrass you at the log-on, but you know, you’re something of a Renaissance man, right?

    Reselman: [Laughter] Right.

    Shimel: I was reading a little bit of your life history, your life story, Bob.

    Reselman: Oh, yeah. Well, I came to tech late. I came to tech in my early 30s, and the reason I got into it is because somebody told me that I could actually compose music on a computer.

    Shimel: [Laughter]

    Reselman: No, it sounds funny, but if you’re a composer—and I don’t mean—

    Shimel: Like in the MIDI days. I hear you, dude. I know people like that.

    Reselman: Yeah, back in the MIDI days, and you know, if you had a string quartet or even something larger, like an octet, to actually hear that going on, to hear it was very hard. You had to go out and either hire a quartet to play or just be really good at imagining, or be able to sit at a piano and be able to pay some stuff. And I’m not the world’s best pianist, so this medium, this technology really opened up a world to me.

    And then one day I’m sitting around and I’m starting to play with this, and I’m writing it, you know, my string quartet and stuff. I said, “You know, I think I could probably do something with programming.” And so, I did. I actually, I learned to program, and I’m one of those people that came in through the back door. Eventually, I ended up at Gateway, at that time, Gateway 2000, and I—

    Shimel: [Cross talk] cows, we remember it.

    Reselman: Yeah, the cows, yeah. I moved from Boston, Massachusetts to Sioux City, Iowa, which was a complete cultural transformation for me. But every day, I went into the future, this big, big building where we were making computers. I learned a lot, and we can talk about that, too.

    And at Gateway, I was really doing a lot of stuff I shouldn’t have been doing, but I did ‘em, anyway. And I mean that, I just, I sort of had to battle my way into technology. And they were very supportive, and I just learned a lot about some real, hardcore tech, working for that company, and for that, I’m ever grateful.

    And so, that was around ’98. Around 2000, I decided to move on, and I had started doing Big 6 consulting, went into Big 6 consulting. I went into New York and I worked in the financial industry for a while, and then I got good at it. Along the way, back around 1995, I published my first book about DB programming, and Wygant has been very good to me. I still get those royalty checks every month. I can’t complain. That’s how I got here—that’s how I got here, you know? And here I am today.

    Shimel: So, Bob, over the last couple years—I mean, look, we’ve been doing, so, DevOps.com has been around four years. You’ve probably been doing writing and RoelBob stuff for, what, three years, two and a half years—something like that?

    Reselman: I think three. We’ve been together for a while, Alan. It’s been, you know, the “Casablanca” of technology, what can I say? We’re on the runway, walking into the fog, right? [Laughter]

    Shimel: [Laughter] Round up the usual suspects.

    Reselman: There are no usual suspects. [Laughter]

    Shimel: But Bob, you know, certainly with the advent of DevOps and a heavy emphasis on automation, but also, it’s not all DevOps, it’s the world we live in, as you’re fond of saying.

    Reselman: Mm-hmm, mm-hmm.

    Shimel: You know, automation and the specter of increased automation over the—you know, not only near term, but long term—is really, it’s a scary thing. It’s scary for me as a parent with teenaged boys in terms of what are they gonna do, but it’s scary for a lot of people, people in the workforce today. And it’s something that you have really given a lot of thought to, you’ve written extensively about it, and that’s what I wanna talk to you about today.

    Reselman: Mm-hmm. Well, I’m happy you do, because I do think it’s important, and I think it’s going to have a growing impact. A lot of people—within technology, we can sort of ________. We’re in the middle of it, and we’re pretty adept at adapting—I don’t know if that’s a real term, but we pick up stuff pretty quickly, and we’re good at getting new stuff onto our fingers very quickly.

    But there’s a whole segment of the culture that has problems with it, to be honest. And, you know, let me be direct. Let me be direct, here. My father, he was a cab driver. He was a cab driver, and when I look at what Uber and Lyft are doing to the cab industry in New York City, it’s pretty amazing. I mean, his first medallion, I think, cost him—I’m making these up, I don’t have the actual data, but I think he paid $250,000.00 for his first medallion. And back then, that was a lot of money. But there were only a set amount of taxicabs on the street, and so, there was a high volume, it was a good investment. Today, because of the ride sharing, share services the value of medallions is dropping dramatically. And that’s just one impact of automation.

    Uber and Lyft could not exist without, I wanna say, two fundamental technologies coming on. First of all, credit cards. The other one is GPS, and the third is cell phones. And you mix all three of those together, and anybody can really be a driver. Why? Because you can pick up qualified customers and bill them without having to worry about being paid. GPS will pretty much tell you where to go, and cell phones provide the mapping technology to get there—all of it highly automated.

    Now, what’s interesting to me is that I wonder about the actual Uber and Lyft drivers now as that automation extends. For example, I take Lyft. I take Lyft all the time, and I’m more of a ride sharer than I am a car owner. And I’m sitting in the back of a car, and I had to go to an appointment, and I started reading a book. And I noticed that we were going in the wrong direction. We were going in the wrong direction. I said to the driver, I said, “You know, we really are going in the wrong direction,” and her response was, “Well, this is where the map is telling me to go.”

    Now, what is relevant here is, how far are we really—what is the purpose of that driver, other than to be an interpreter of map data and to manipulate the technology accordingly? And that’s not that far from robotics, and people—

    Shimel: No, it’s not. And actually, I mean, Bob, Uber and Lyft’s end game is to go autonomous, obviously, right?

    Reselman: Right.

    Shimel: And take the driver out of it altogether. But the interesting thing, I’ve had, specifically around Uber and Lyft, but they’re really poster childs for this, right?

    Reselman: Mm-hmm.

    Shimel: When we start thinking about the future of autonomous vehicles, we start thinking about, what really is—what is the disruption in Uber? You mentioned three key technologies, but is Uber really a technology disruption company, or is Uber a company that, what it disrupted was, by taking advantage of all of the excess vehicles and time that drivers have and putting that to good use? And so, was that the true disruption there, or was it the technology that was the disruption, and part and parcel with that technology is the automation?

    Reselman: Right. I think the disruption—it’s the aggregation of the technology which is the disruptor. Now, what is being disrupted? I think there’s a fundamental social disruption going on. The rules of existing as an employee or a wage earner or a value creator in society is changing. And Uber’s talent in terms of transportation—because it’s everywhere, you see everybody getting into those Uber cars. But that’s really inconsequential compared to the larger impacts of transportation.

    So, for example, container shipping is, Swedes Burkett just released a thorough—and again, people can write me and I’ll give them the exact data, because I don’t have it in front of me—but I believe it’s called the Burkett, and that’s a large container ship that’s completely robotic. So, imagine how much containers get shipped on the open seas that have crews. Now, those crews will go away.

    The same as with trucking. Trucking is really low hanging fruit. There are 3,000,000 truck drivers, and Uber is active in the trucking—automated trucking industry. So, they’re looking to automate that, and that’s gonna have a disruption.

    I wrote—the last article I wrote for you all was called “Coming Apart in the Age of Automation,” and the unintended impact here is that we really are creating a bifurcated society in which one class has, can master the technology or becomes the merit class, and the other class is just sort of hanging on. And it’s a sad thing to say, but it is true. And, as we look around current events, we can see that more and more.

    Now, the good news here is that we’re in a—we are in a good position. And what I mean by that is that, if we go back and we look at the history of technology, particularly around the advent of mass production in consumer technology, which is really the automobile. The automobile really was a game changer, because it was intended to be a consumer product once Henry Ford figured out how to do the assembly part. And because it became a consumer product, it really lifted the whole middle class. It became—if you were coming off a farm in Georgia, you could go to Detroit, and without having to learn a whole lot of new skills, become a wage earner in a factory.

    That’s good. Nobody really understood the impact of the internal combustion engine back in 1900 or 1910, that in 100 years, this would have a significant impact. And what I hope we’ve learned along the way is that technology does have an impact, along with sociological and economic. And we can start planning for that accordingly. Sadly, what I’m not hearing is that planning. People hear—the argument is, technology, yes, will always displace people. There are no more people picking up the horse dung on the streets of New York. Those people went to work in factories, et cetera, et cetera. In other words, technology destroys jobs, but it creates more jobs.

    But we’re not hearing any sort of ancillary planning of what the downside might look like, and if there is a downside—which there might very well be—how we’re going to address that.

    Shimel: Yep. I—you know, Bob, maybe I’m cynical in my old age. [Laughter] I—unfortunately, planning is not our long suit, right? We live in a financial world where we live quarter to quarter, week by week, you know? A bad quarter can cost a CEO their job and lose trillions or billions—not trillions, but billions of dollars of market capitalization.

    Reselman: Mm-hmm.

    Shimel: The fact of the matter is, if you believe the media, most people in our age group, Bob, have not put away enough money for retirement.

    Reselman: Mm-hmm, mm-hmm.

    Shimel: We don’t believe in science or truth, [Laughter] and so we can’t even plan around what to do about climate change. Why should this be any different?

    Reselman: Well, I don’t know if I agree with your assessment completely.

    Shimel: Okay.

    Reselman: Because I just got through reading a book by Harari about, it’s an assessment of current conditions and future. And people forget that famine and people dying of starvation even 50 to 60 years ago was a common day event. A lot of people in China starved to death. That really did happen. People in Ireland, in 1840 when the potato famine came along, they starved to death. You didn’t have enough food, and you died. Death due to starvation is still around, but it’s not commonplace—nowhere near the condition that it used to be.

    The other thing is, when we look at warfare—yes, there are wars going on and there are mutual wars, but there hasn’t been a war on the scale of World War II since World War II. So, there’s stuff going on that sorta gets hidden behind all the—what would we say—the fascination with the bad stuff.

    The other thing to think about in terms of us as technologists is that planning is still part of the industrial fabric. What do I mean by that? It takes five years to design and manufacture a car. I learned this when I worked at Edmonds. Pretty much, if you start looking at model years, the big model changes are in the fifth year. Pretty much, if you came out with a Car A—in year one, you’ll have A, then year two, what used to be options become standard and then more options become standard. And then, by year five, you have enough research in place and enough retooling of factories in place to create a new vehicle and put it on the market itself.

    So, industry does have the ability to plan. I mean, just look—I mean, if we look at SpaceX, bringing that rocket back and just being able to send a rocket up, you know, one of those cylinder rockets, right, that you used to imagine from the ‘50s goes up? And we used to just blow ‘em up and leave them in space. Now, we can actually bring them down and allow that piece of pipe with rocket fuel in it to land safely on land. That’s pretty amazing. You can’t plan that in three months. That takes years and years and years of planning.

    So, we have the ability to plan. The question is, in terms of our social imperatives, and that becomes a real question. So, why—what’s stopping people from saving? Why are people afraid? Why is fear so high now? And then also, going back to jobs as, we’ll call them no-skill jobs, start being eliminated from the landscape because grunt work is always the easiest to replace; thinking work is harder. Then, what do we do about that?

    And there are people out there offering solutions, but they are pretty dramatic, and there’s two, and they’re dramatic, and to even start contemplating that really requires a lot of courage.

    The first one is, is that there’s a good case to be made that we are at the end of the consumer based economy. Again, let’s go back to Ford. You know, an automobile for everybody changed everything. And when you look at it, you know, how many cars can Bill Gates drive? Well, if indeed, he had 365 cars in his garage, he could drive a different one every day. The fact is, he probably doesn’t, and he probably takes an Uber. So, really, in the future, you know, we’re all gonna be sharing cars.

    So, this notion of ________, and I didn’t do a good job explaining it. In other words, what I’m saying is that, for a lot of people, having devices and technology is what makes the economy run. Everybody needs a cell phone. Having mass distribution of cell phones makes the economy run. Having mass distribution of food makes the economy run. Mass distribution, mass distribution, mass distribution.

    Well, at some point now, what’s happening is, we can produce as much as we like. Production is no longer a problem. Two hundred years ago, production was a problem. The factories couldn’t make the stuff fast enough. Now, the factories can. So, now we have infinite production, which means we have infinite consumption, which means we have a problem with too much plastic in the water, and too much carbon monoxide in the air.

    Shimel: Bob, I’m gonna butt in here, if you don’t mind.

    Reselman: Okay.

    Shimel: So, I just got back from China last month.

    Reselman: Okay.

    Shimel: There’s a real problem there, right? Because this is—they’re living it, right? And, you know, we look at the world’s steel market and tariffs and all that stuff, a lot of it is being driven by—China has built over capacity in terms of what they can actually use and even sell at a decent margin in terms of steel.

    Reselman: Mm-hmm.

    Shimel: But not just steel, they are producing solar panels, cellular phones. They just—in other words, they are the kings of this, “Hey, we’ll produce as much as we possibly can produce because we’re gonna, if we’re not gonna consume it, we’re gonna sell it in the world market, and if we can’t make a profit on it, well, we’re not capitalists, anyway, right?”

    But an interesting dichotomy that I saw there was that they still are manually labor intensive in certain things. So, their streets are pretty clean in the cities, and the streets are clean because, on every street, there’s a cadre of people walking around with bamboo poles and palm fronds, kinda thing—literally sweeping the streets. And they sweep it into a pile and then some other person comes by and they have all these uniforms. And it comes by on a machine, like a Zamboni machine excepts it a vacuum, and sucks up what that people sweep.

    Reselman: Mm-hmm.

    Shimel: It’s almost like busy work to me, but what was fascinating to me is that, on one end, I took the bullet train from Shanghai to Beijing, right, and 300 and something kilometers an hour. And all I could see out the window, Bob, were endless cranes and towers going up, right? Not just a building, but cities and towns being built one after the next, and all built around factories. They’re like old factory towns, they kinda looked like, right?

    Reselman: Mm-hmm, mm-hmm.

    Shimel: So, they got the infinite capacity to build things, but I really question the infinite capacity to pay for things, to consume these things.

    Reselman: Right. Well, you hit it on the head. It’s the notion of payment. That’s sort of like, it’s like an assumption that we might have to start questioning, which leads into the second point that I was gonna bring up. You read my mind, Alan—and do my a favor, when you’re reading my mind, please clean up after yourself.

    Shimel: [Laughter] Okay.

    Reselman: Right, so the first point is, we have to start examining the role of consumption as a driver of an economy. We just gotta start looking at that. That’s a big question with incredible ramifications.

    The second one becomes this notion of paying for stuff in order to get what you want. And to—let me share a real life funny. My wife has decided that she needs—she wants to get rid of a chair we never use. It’s a nice leather chair that we never, ever use, and we paid, I think, $600—whatever it was, it was too much. I’m not a decorator, but she paid it, and now she’s saying, “I wanna sell it for $200.”

    And so, she puts the ad out on Craigslist and nobody’s biting, nobody’s biting. Why isn’t anybody biting? Because my suspicion is, it’s a good price for a $600 chair, but they can get ‘em for free. They can get probably an equal chair for free. And, if you look at the cell phone, I mean, we’re giving away cell phones. We’re giving it all away, we really are.

    And so, this notion of, what you’re saying is, how are people gonna pay for it? Probably they’re not. Either one of two things are gonna happen. Either the buildings are gonna be left unoccupied and it’s gonna be, there’s a downward recession—or the alternative is to blast credit into the economy to create money and to have that money become a purchasing agent. Is there wealth created? Is there value created? I don’t know about that. I don’t know about that. But are there transactions created? Yes.

    So, I’m being long-winded by saying that it might be coming time to start looking at a serious examination of universal basic income. And let’s just sprinkle the fairy dust for a moment, and let’s sprinkle the fairy dust and say that we’ve just—everything is great, everybody’s just calmed down. They understand that automation is great and if we let machines have their way, the machines can do just about everything now. And every week, you know, you get a check in the mail that allows you to go down to the grocery store or, better yet, interact with Amazon Prime, and the drone shows up with your food. And you go to your TV set and there’s your streaming TV. And some people decide they wanna be philosophers ________, so there are brain surgeons, and other people just decide they wanna sit around and play video games all day.

    There’s our future, right? Is that so bad? Is that so bad? And people say, “Well, how will we innovate? How will we go forward?” And my question—and I don’t have an answer for this—is, I wonder if somebody who gets into something like brain surgery for the money or curing disease for the money? Maybe the recognition, we don’t know. But the notion of universal basic income, if you take away the moral reservations about—what would they call it? The moral risk, right, becomes buyable.

    The sad thing is, is that any—the experiments that are being ________ aren’t real world. And what do I mean by that? They tried in Canada to ________. And I forget the details; I’ll mail it to your listeners if they want it. They’re running UBI on $1,000 a month. The test group got $1,000 a month. Well, gee, I mean, can you really live on $1,000 a month? That’s one thing. Whereas, if you go to another country that has universal basic income, and the poster child is Cyprus. Cyprus gives every citizen 500 Euros a month. The reason it’s relevant here is that a rent of an apartment in Cyprus is only 520 Euros a month. So, 500 Euros a month becomes, between—with two people, 1,000 Euros a month becomes a viable amount and a reasonable standard of living.

    That’s where UBI needs to be. We need to be starting to talk about UBI numbers in the area of $40,000, $50,000, $60,000 a year per family, and then we have to deal with the ramifications. And the ramifications really aren’t so much economic as they are social. What happens when you move the social structures that work bonds? In other words, what happens when a whole society no longer has to get up in the morning and go to work? What happens then?

    And that becomes the danger point, because most people have no idea.

    Shimel: Huh. Excellent. I think—yeah. I don’t disagree with you, there.

    Reselman: Well, again, I’m not looking for conflict or disagreement. This is a great discussion, but for our listeners out there, the point is—we are in technology. We are the people that write the scripts. There are other people that do the automation. We are the people that are making the robots. We’re doing all this. And we’re in a good position now, because unlike Henry Ford, who really didn’t think it through with regard to what an automobile would do over a period of 100 years, whereas one of the engineers at Sony did in terms of television. A friend of mine’s wife’s father worked at Sony, and he raised a question to one of his engineers back in—I think it was in the ‘80s. And he said, “You know, we’re selling a lot of Trinitrons. What are we gonna do when these all come back?” At least he posed the question.

    So, if anything, for the listeners out there that I hope they consider is, what do we do when we’ve become very good at all this? What do we do when we’ve created a framework and a fabric of automation where—and labor almost becomes unnecessary? What do we do, then? And what are the ideas behind that? And that’s where I wish there was more conversation, at the least. And not be on, “There will always be more jobs” or the fantastic stuff, but real, concrete, well researched conversation.

    Shimel: Excellent. Bob, I’d love to continue this conversation, but we are so way over our time. [Laughter]

    Reselman: Oh, I’m sorry, I’m sorry.

    Shimel: That’s okay! We’re gonna need to pick it up on another DevOps Chat.

    Reselman: Okay.

    Shimel: Which is great. I bet next month, we’ll do it again.

    Reselman: Sure, sure. Yeah. I’ll do that. I’ll make the coffee. The dog’s been very good here, he’s been very quiet. He understands that he’s being recorded, so.

    Shimel: Otherwise we’ll automate him out of a job. [Laughter]

    Reselman: Yeah. [Laughter]

    Shimel: Anyway, Bob Reselman—RoelBob, author, futurist, commenting on the state of the world today—thanks for being our guest on this DevOps Chat. We’ll continue this conversation on another DevOps Chat soon, but for now, this is Alan Shimel, and you’ve just listened to a DevOps Chat. Have a great day, everyone.

    — Alan Shimel

  • 4 Ways to Tackle Common Test Automation Pitfalls

    4 Ways to Tackle Common Test Automation Pitfalls

    The demand for higher-quality products and new features delivered at breakneck speeds has the average engineer struggling just to stay afloat. With demands rising but resources not always following suit, engineering teams are embracing automation as a key testing option.

    According to a report by advisory firm KPMG, test automation increased by 85 percent from 2015 to 2017 across all industries. Automation is one way to address this accelerated development schedule, but it can also introduce other problems. To ensure that doesn’t happen, there are four common pitfalls that engineering teams need to look out for.

    Problem No. 1: Right Job, Wrong Tools

    It’s tough to build a shed with a spatula and a sewing needle. Likewise, you can’t build a successful test automation suite if the tools used don’t fit your company’s testing strategy.

    The solution: Pick the right framework for your suite.

    The first question you need to ask yourself is: Should you build or buy your test automation framework? The answer likely depends on how mature your testing structure is. Smaller teams new to the technology typically are best-served starting with an off-the-shelf enterprise solution. This approach makes it easier to get up and running quickly, while having the support to handle software bugs along the way.

    Larger, more mature testing teams may have more to gain from an open source automation framework. This cost-effective approach provides flexibility and customization, but often requires advanced technical expertise and the luxury of time to build such a solution.

    Problem No. 2: Living Fast, Dying Young

    Many automation projects never make it off the ground because teams move too fast and automate too much, too soon. Inserting automation into the delivery pipeline prematurely will cause workflow and build issues more often than not.

    The solution: Build test automation into your pipeline incrementally.

    It may be tempting to run full speed as soon as you are set up, but the truth is you need to take your time for developers to build confidence in the testing process. Once that confidence is established and you’re receiving valuable feedback, you will have the full team’s support as you continue to scale your automation strategy.

    Problem No. 3: Automation Without Documentation

    Automation can make testing easy. Sometimes too easy, to the point where engineers will simply kick back a failed test without looking into the reason it failed in the first place. Oftentimes, these failures are the result of an outdated testing script or an issue with the test environment, and not with the code at all.

    The solution: Triage automation test results just like manual bugs.

    Instituting an intermediary triage stage will save your engineering team time in the long run. There’s no need to treat your processes for automation results any different than you would bugs found manually. Having access to materials such as activity logs and screenshots will only help to strengthen and speed the triage process.

    Problem No. 4: Setting and Forgetting

    Automation makes testing quicker and easier. That’s why you invested in it in the first place, right? Unfortunately, there is more to such solutions than just plugging them in and letting them run.

    The solution: Take maintenance into account when building your framework.

    Many teams are surprised by the maintenance required to keep test automation suites running smoothly and effectively. They shouldn’t be. Solutions need to be updated continually to address user interface changes, new operating systems and browsers, and automation library changes. The maintenance of third-party dependencies also needs to be considered before automation is used for production test runs.

    Maintaining your automation suite is a continuous process. Make sure you have enough testing resources—either in-house, outsourced, crowdtesting or a combination of all three—to ensure your efforts don’t go to waste.

    Measure Twice, Implement Once

    Make no mistake, automation is more than a quick fix. If you are going to spend the time and money necessary to build a successful strategy, you should make sure to set yourself up with a solid foundation. A framework that is thrown together within days but falls apart in hours will only serve to make automation seem like an unpalatable solution within your testing department. Having the right partners in place and the right solution from the start will help automation become a reality in your company, and can bring the promises of speed and flexibility to life.

    — Drew Horn