devopsy.kinsta.cloud

Tag: devops

  • Getting the Most Out of QA in Complex Environments

    Getting the Most Out of QA in Complex Environments

    We live in a world in which software is increasingly dominant. Not only do we rely ever more on software, but its complexity is becoming even greater. And with increased complexity, bugs are more likely to be intermittent, making failures difficult to reproduce. Sometimes this non-determinism results in failures never getting fixed. Any unfixed bug is potentially a security breach or catastrophic customer outage waiting to happen. With such risks on the line, ensuring your software is of the highest quality is essential to running a successful operation.

    To cope with this complexity while still providing some assurance of delivered software quality, the DevOps industry has embraced a variety of automated testing regimes. A development team of a given size is able to run many more tests than it could before and must triage, and attempt to resolve, a correspondingly larger number of test failures. Diagnosing the cause of each test failure can still take a lot of time, particularly if the problem is intermittent or otherwise not easily reproducible. In fact, developers can spend on average as much as 50 percent of their programming time debugging, not coding. Think of all the innovation that could occur if that time were reallocated.

    Traditional QA

    When it comes to Quality Assurance (QA), developers and testers are all aware of the sequence of deliverables, beginning with development delivering an untested product to QA, which releases the tested and approved product to the end user. However, when a bug is found, QA and Development must communicate with one another to solve the issue quickly. The effectiveness of the delivery channel between QA and Development hinges on the quality of the information about the failure.

    Some common challenges raised by inefficient QA processes include:

    • Complex control flow – Difficult to make inferences about how a failure unfolded
    • Non-deterministic failures – Hard to reliably reproduce a failure to investigate the root cause
    • International R&D – Collaboration is made more difficult by geographic separation

    Conventional test systems inform that there is a bug but offer limited information about the cause. Workflows such as continuous integration (CI) often offer clues, such as informing which commit to the codebase caused the failure. However, there are several cases where CI cannot directly help identify problematic code changes. For example, the triggering code change may be entirely correct, yet cause a pre-existing bug to manifest. The developer cannot simply stare at the modification in the expectation that the source of the bug will eventually appear. Conversely, the failure may not easily reproduce for the developers even if they run the same test again. In short, CI is often very good at making the easier bugs very easy to fix, but typically is of little help with the more difficult bugs, particularly intermittent ones.

    The Next Evolution of QA

    To bridge the gap between identifying a failure in the QA process and resolution by development, DevOps teams have adopted a variety of technologies to complement their automated testing setups. New to this scene is technology capable of recording all or part of a program’s execution for subsequent replay and analysis, capturing test failures as they happen. The recording contains all the information a developer needs to understand the exact set of conditions that led to the test failure. It can be analyzed on different machines to the one on which the failure occurred, facilitating collaboration between colleagues who can work on separate machines to resolve the same issue—a particularly useful benefit for large software companies with geographically distributed teams. By gaining the ability to debug an exact replica of the failure, developers immediately reduce the time and effort required to diagnose and fix failures, therefore speeding the development cycle.

    Being able to generate recordings of failed tests, especially those intermittent issues which might not otherwise get fixed, coupled with the productivity gains of increased collaboration between development and QA allows companies to maintain a competitive advantage in a volatile marketplace.

    About the Author / Greg Law

    Greg is the co-founder and CEO of Undo. Greg has 20 years’ experience in the software industry and has held development and management roles at companies including the pioneering British computer firm Acorn, as well as fast-growing startups, NexWave and Solarflare. Greg left Solarflare in 2012 to lead Undo as CEO and has overseen the company as it transitioned from the shed in his back garden to a scalable award-winning business. Greg holds a PhD from City University, London, that was nominated for the 2001 British Computer Society Distinguished Dissertation Award. He lives in Cambridge, UK with his wife and two children.

  • CD 101 Podcast: How to Build the Modern Software Factory with Agile Development and Continuous Delivery

    CD 101 Podcast: How to Build the Modern Software Factory with Agile Development and Continuous Delivery

    And now, for Episode 3 … you decide if it beats “Star Wars – Revenge of the Sith.”

    I think we accidentally just set the bar pretty low, but …

    … here we go. Let’s begin with a prerequisite pithy quote from an objective industry observer:

    “If agile software development was the opening act to a great performance, continuous delivery is the headliner,” according to Kurt Bittner of Forrester Research.

    Kurt explains this concept further by saying, “The pace at which consumers expect change is causing a crisis in application development and delivery … agile was a good start, but it wasn’t sufficient to drive better business results; continuous delivery forges the broken link in the value chain, connecting business strategy with business results.”

    So there, you have it.  At least according to Forrester, continuous delivery (CD) is one of the most important evolutions of agile methodology within the modern software factory. But, there’s more.

    Andrew Binstock from Dr. Dobbs fairly well echoes this sentiment, saying: “It’s becoming clear that agile alone is no longer sufficient to keep up with the demands of the present day … software complexity and the need for constant updates are making it difficult for leading edge organizations to keep up without moving beyond agile and embracing continuous delivery.”

    Episode 3 of our podcast series discusses the importance of Agile Transformation along WITH Continuous Delivery to automated some of the development, test, and release efforts to remove some of the bottlenecks downstream in the software development life cycle in the build, test and release phases.

    Lean Agile + CD can create these 1+1=3 types of results.

    Episode 3 of the Continuous Delivery 101 Podcast can be found by:

    • Listening to it on your computer on YouTube
    • Downloading it from iTunes store
    • Downloading the podcast from your Podcast App by searching for “Continuous Delivery 101 podcast”

    Thanks for listening!

    — Scott Edwards

  • Digital Transformation and the DevOps Chaos Theory

    Digital Transformation and the DevOps Chaos Theory

    With the threat from agile startups disrupting markets across the globe, large enterprises are increasingly focused on moving to a more agile approach to business. Most organizations already have begun the digital transformation (DX) journey, but the fact that this transformation is still in its infancy and not completely finalized for many demonstrates the fluid and evolving nature of DX. Multiple IT technologies, processes, applications, systems and protocols need to be adopted and updated on a regular basis for businesses to keep abreast of changes. This does, of course, result in significant disruption for all involved.

    With this in mind, DevOps principles are beginning to have much greater impact, with the true value of this methodology being identified through a new approach. As development velocity increases, and the scale of the enterprise also increases, businesses will develop a much greater reliance on DevOps principles to rein in the chaos associated with continuous development that’s being spurred on by the pace of digital service development and increased automation.

    The key to managing and minimizing the resulting chaos is close collaboration and communication between the IT team members responsible for service development and delivery. Without this, the need for a continuous delivery pipeline operating at speed and scale, will quickly get out of control.

    The DevOps Chaos Theory

    To understand the challenges in this new business environment, it is useful to look at this at a more granular level, through the framework of the DevOps Chaos Theory.

    The pace of innovation is measured as the Velocity (V), or the number of new software releases deployed in a production environment in a defined time period. The Scale (S) factor is measured as the overall number of IT staff involved in service delivery and management in production environments, such as DevOps, SecOps, QA, system architects, DBAs, NetOps and help desk. Interaction between these team members brings the potential for miscommunication, which will increase the overall chaos. The maximum number of interactions between these IT members is S * (S – 1)/ 2, and for high-scale organizations it approaches S2/2. Based on these considerations, a logical hypothesis would identify the system-level Chaos (C) in production environments as C = K * V * S2.  K is the normalization factor that may change based on the overall adoption of DX in a specific industry and the effectiveness of collaboration and communication between the IT team members.

    Minimizing Disruption

    Collaboration between departments within the business is important to ensure the chaos is controlled. There is no doubt that automation tools play an important role in continuous delivery and allowing organizations to operate at the speed and scale they need to. However, enterprises must identify the level of constraint placed upon the IT operations team. This is crucial to establish what changes need to be made and what service performance management technology must be introduced, to prevent operations from becoming a bottleneck to the continuous service delivery cycle inherent to DX.

    Key performance indicators (KPIs) are critical when it comes to service delivery, particularly when you consider that this combines the entire stack into a single system. This stack is comprised of physical, virtual, wired and wireless layers of compute, storage and networking infrastructure and application that run at the top of the stack to deliver services consumed by end users. Using a variety of network, infrastructure and application performance management tools will obscure the system-level view across all the layers of the service stack and their interdependencies. Monitoring system-level KPIs requires access to reliable data sources, such as network traffic. An effective instrumentation of these data sources will play a key role in proactively identifying the root cause of service issues and thus reining in chaos.

    Enterprises must be able to effectively analyze the monitored data to gain insight into all the infrastructure subsystems and applications interdependencies to establish a comprehensive view of their services, accessing both real-time and historic information. In addition, effective management at a human level also should form an important part of a company’s DX strategy, if chaos is to be mitigated and crisis averted.

    More and more companies are realizing that DX offers a wealth of opportunity, but it’s crucial to understand that harnessing these opportunities requires strategy and forethought. Monitoring and managing systems will be vital, as will DevOps principles, as more processes are automated and data plays an increasingly central role to any company.

    About the Author / Michael Segal

    Michael Segal is vice president of strategy at NetScout. His product management experience spans across 10 years at Cisco Systems, where he managed all aspects of product line life cycles for several successful product lines. Michael’s technical areas of expertise include SaaS/cloud, virtualization, mobile IP, security, IP networking, Wi-Fi/wireless, VoIP and remote access. Michael holds patents in areas of networking and wireless mobility. Connect with him on LinkedIn and Twitter.

  • DevOps is Dead! Long Live DevOps!

    DevOps is Dead! Long Live DevOps!

    Some are seekers on the quest for the one, true DevOps. They were misled. I’m here to say: Give it up. Whatever you find at the end of that journey isn’t it. That one true DevOps is dead. Dead and buried. The search is pointless or, kind of worse: The search misses the point altogether.

    DevOps began as a sort of a living philosophy: about inclusion rather than exclusion, raises up rather than chastises, increases resilience rather than assigns blame, makes smarter and more awesome rather than defines process and builds bunkers. At any rate, it was also deliberately never strictly defined.

    In 2010, it seemed largely about Application Release Automation (ARA), monitoring, configuration management and a lot of beginning discussion about culture and teams. By 2015, a lot of CI/CD, containers and APIs had been added. The dates are rough but my point is: That’s all still there but now DevOps discussions today also include service design and microservices. Oh, and the new shiny going by the term “serverless.” It is about all of IT as it is naturally adapting.

    And this emergent, inclusive content is possible because it’s always just people talking practices and sharing how to optimally do things. Infra as code, “cattle, not pets,” webscale, version and automate all the things, horses not just unicorns, etc. Lots of conversations, insights sharing, presenting.

    Good times.

    There are more DevOps Days naturally occurring globally this year in 2017 than ever before. Note I wrote “naturally”—DevOps was always an organic movement, a grouped (and, whoa, global) response to increased app release pressures and the desire to select for teamwork over turf wars.

    So we started with DevOpsDays and those blossomed all over. Then we got the Phoenix Project, the DevOps Enterprise Summit (now in US and EU formats!), and more great books including “Infrastructure as Code,” “System Reliability Engineering” and, finally, “The DevOps Handbook.” It’s all solid, informative stuff and I believe as a community we’re smarter, happier, and far more effective because of it.

    Even those naysayer analysts—you know who you are—have come around to accepting the DevOps goodness.

    DevOps lives when we continuously adapt to managing emergent properties spawning system-level feedback loops in our IT and across our businesses. To do better, faster, higher quality things to delight the customers.

    Any discussion of DevOps is truly about continual IT innovation adaptation because the rate of IT change is also changing. Fast and faster. All that means starting with the roots like CLAMS and moving forward with containers and embracing the journey to quickly delivering better customer experiences.

    So, the concept of DevOps is evolving, just as our understanding of what’s needed is evolving.

    — Christopher Little

  • Release Automation: Delivering the Big Quality Payoff

    Release Automation: Delivering the Big Quality Payoff

    Have you ever gone down the path of testing the latest release of an application only to find out that you had the wrong version?

    Maybe you accidentally grabbed the wrong build or you didn’t have the correct configuration file for the environment you were testing against—or your database wasn’t updated correctly, or the script you were using was still pointing to a prior version of the software.

    Whatever the case, we can agree that keeping track of all the various artifacts, database schema changes, configuration parameters and other components needed to accurately test and deploy an application is both time-consuming and prone to errors.

    Today, many companies are looking to DevOps, continuous delivery and agile development methodologies to shorten their application delivery cycles and reduce the number of errors and the costs associated with application deployment processes. Nearly all enterprise companies are software companies, and their mere existence depends on delivering differentiating products and services via software to their customers.

    It’s imperative to be able to react to customer demands and competitive pressures quickly, if not immediately, to stay ahead of the competition. Gone are the days of yearly release cycles.

    Today we see companies deploying new capabilities into production environments on a monthly, weekly or even daily basis. At some companies, hundreds, if not thousands, of deployments are occurring across dev, test and production environments daily. The old methodologies we once used simply can’t support this type of volume and cadence.

    Employing Release Automation

    So, how are these companies transitioning to this new way of thinking? In a word—automation; specifically, by automating early and often.

    Everything about your release process is a candidate for automation. This includes environment provisioning and configuration automation, build automation, test automation and release and deployment automation.

    A customer of ours recently implemented CA Release Automation, and within eight weeks had automated 90 percent of its deployments. Deployments that once took more than five hours and a team of people now take a matter of minutes.

    “This not only saves us a huge amount of time, but it also mitigates the risk of human error being introduced by manual processes,” said Tim Dallmann, platform engineer at Jewelers Mutual.

    Another customer, a major airline, implemented CA Release Automation and immediately reduced their production outages from an average of 237 over a three-month period, down to 15, seven, six and five over the following four months.

    And Molina Medicaid Solutions reduced their cost of human error by 90 percent, all the while responding quicker to emergency deployment requests and improving deployment quality.

    Automation is critical, but I believe these results prove that implementing a framework to manage and deploy release processes in addition to automation works even better.

    Increased Flexibility and Visibility

    Continuous delivery helps break down barriers often seen between development and operations teams. It provides, even forces, a more collaborative approach and automation is a key enabler of this.

    “One of the best things about automation is that it gives us the flexibility to skill-up end users—deployments in our test environments are no longer solely the responsibility of the operations or IT teams,” explained Dallmann.

    With an application release automation (ARA) solution, artifact, build, configuration and release processes are no longer tracked with spreadsheets or embedded in complicated scripts.

    Increased visibility into these processes ultimately enables all stakeholders to take a more active role in the release process, and access to real-time information can significantly reduce the amount of time and resources needed to resolve and recover from problems when they do occur.

    Automation leads to:

    Integrating with the Ecosystem

    An enterprise ARA solution can help you create a single control point to streamline all your application delivery processes for better predictability and reduced risk. A critical component of this is the ability to integrate and orchestrate tools and technologies required along the continuous delivery pipeline, including source control, automated testing tools, provisioning and configuration management solutions and change management and performance management solutions.

    Integration with an application lifecycle management solution can provide even further alignment, governance and traceability between development projects and what is ultimately being tested and promoted to production.

    “By integrating the two solutions, we will have a complete audit trail of deployments to help us understand how, where and by whom stories have changed,” said Phil Nickolai, director of application services at Jewelers Mutual.

    “What we really needed was a solution to streamline our whole way of working,” he said. “We had numerous people working on projects, competing for resources and causing complexity. Now we’re back in control and getting smarter every day.”

    The Time Is Now

    Let’s get rid of the problem that exists between the keyboard and information kept in spreadsheets, scripts or emails. Not only will you stop wasting time testing the wrong version of an application, but you can also ensure you have the right test data, the appropriate test cases and the correct configuration parameters for your environment.

    Stress-inducing release weekends and nights become a thing of the past. Developers can spend more time on developing innovative capabilities that generate revenue and keep customers coming back for more.

    — Tim Mueting

  • The Leadership Suite DevOps and Business Alignment Success Guide

    The Leadership Suite DevOps and Business Alignment Success Guide

    There’s not much point to DevOps if the business isn’t directly benefiting through increased efficiency, productivity and, hopefully, profitability. This is possible only when IT and DevOps teams are delivering the technology the business actually needs to succeed and compete.

    As IBM director in IBM Cloud writes in his post, “Putting the ‘Biz’ in DevOps“: “The goal in any meaningful DevOps practice is to reduce the time and improve the efficiency in moving from the “Business Need” on the left to the “It’s Live!” on the right.”

    That alignment, while essential, isn’t easy to achieve. As I mentioned previously in my post, “The Big Digital Transformation Trends Through 2017,” the Deloitte 2016 – 2017 Global CIO Survey found that the expectations business has for IT are out of sync when it comes to what IT actually can deliver. The survey found this to be true when it comes to customer focus, technology-enabled business growth and innovation. For example, “even though 57 percent of the CIOs surveyed said that customers were their organization’s top business priority, less than half were involved in delivering customer experience (45 percent) or working on customer acquisition, retention and loyalty (44 percent),” that report found.

    That survey also found, startlingly, that while only 5 percent of organizations say that strategic alignment of IT activities with business strategy is a leading-class capability in their organization, 80 percent of organizations believe such alignment is critical to success.

    With this in mind, we’ve cultivated some of the best stories and other content on devopsy.kinsta.cloud when it comes to effective alignment of DevOps efforts and business strategy.

    The Big Digital Transformation Trends Through 2017

    Some of the most important trends in 2017 will include CIOs struggling to break out of the role of IT plumber and to better align the business with IT.

    How to Align Your DevOps and Cloud Initiatives – devopsy.kinsta.cloud

    One of the best ways to align with the business is to move software more swiftly with continuous delivery efforts. In this post, Michael Schmidt, head of the Automic DevOps Practice, details how to best manage IaaS, PaaS along with DevOps so that organizations can develop more quickly, and rapidly move to continuous delivery.

    The Conundrum of Adopting DevOps within Organizational Constraints

    In this post, devopsy.kinsta.cloud regular contributor JP Morgenthal explains that as with most changes within IT, with DevOps adoption, there is a need for bottom-up support as well as a top-down requirement that provides the coverage, financing, motivation and accountability to the business to enable change to occur.

    Putting the ‘Biz’ in DevOps

    Here, Rick Weaver, director IBM Cloud, explains how by adopting the right business-oriented metrics will help expand DevOps capabilities into a broader, more meaningful “BizDevOps” practices.

    Enterprise DevOps: Organizational Change a Must

    In this article, Sanjeev Sharma, IBM Worldwide lead, details the principles necessary to foster application delivery team alignment from a people and team perspective—something that is essential if teams are to successfully align with DevOps.

    It’s Time to Couple Security, Business Leadership

    In this post, yours truly reviews the importance of aligning security and business leadership, and if organizations conducted themselves that way, there’d be a much smaller gap between security teams and their organization’s board of directors when it came to cybersecurity expectations and reality.

    — George V. Hulme

  • Boosting Time-to-Market by Improving Software Development

    Boosting Time-to-Market by Improving Software Development

    Today’s business environments require “agility” in terms of being able to quickly understand and adapt to information, trends and new developments. For example, a company might employ a business intelligence suite that provides them with real-time information on product sales, which allows them to dynamically adjust content or strategy.

    Set a Baseline

    You can’t measure improvement in a business process without first establishing a baseline. The first step in reducing the time-to-market for software development is to look closely at the current development process. Review the steps involved in turning an idea into a live product or product feature and identify any bottlenecks, inefficiencies and constraints. Once this review is complete, set realistic goals that reflect the current situation and the improvements you want to see within a certain time period.

    Eliminate and Optimize

    During the review and baseline phase, you might come across activities that do not add value and do not speed up the process. Perhaps there are some unnecessary meetings during the mid-phase of the development process that typically do not uncover any problems and hold no real value. Or, there’s a documentation step that is a drain on human capital and takes away valuable time from testing and innovation.

    Identifying problems and bottlenecks is vital, but the efforts will be wasted if there aren’t open lines of communication. Poor communication causes software release delays, so establish efficient processes, set up the right team structure and adopt tools and technologies that allow transparent and fast communication between cross-functional teams. When it comes to teams, you want to find the right balance of staff. Generally, a winning team includes the right analysts, marketing managers and DevOps resources who can work together towards a common goal.

    Streamlining and Developing Incrementally

    As the team moves into development, there are steps you can take to increase efficiency. Independent tasks should be performed in tandem; for example, test scenarios built while various features are defined. Do not wait until development is completed before creating test environments; encourage the team to split parallel tasks that best match with their individual talents.

    When it comes to enhancements for business apps, there’s an inclination to go for the “home run” by greatly changing the application and including many new features with every update. For reliability and speed to reaching the market, you instead want an incremental approach, by which you develop controllable enhancements and bug fixes that provide immediate value to the users. Prioritize the “wish list” of feature sets so you can better manage and plan the updates that will go into future releases. Get buy-in from other departments and then build and create an enhancements schedule.

    Test Often and Embrace Automation

    In addition to having testers test the application, you should actively engage with clients and select users early in the development process so they can provide input on the overall functionality and user interface as well as help discover bugs. Your time-to-market can be greatly impacted if bugs aren’t caught early on, and you might even need to pull a newly launched application if the glitches impact users adversely.

    Improving this process requires defined and repeatable testing procedures and, to reduce time-to-market, these procedures must be automated at least partially.

    Consider these other benefits of software testing that will improve your DevOps:

    • Discovering bugs and software errors can improve the system’s capacity
    • Testing can improve the security of your applications
    • Improve customer engagement and satisfaction through a high QoE score
    • Reduce the total cost of ownership
    • Better meet industry standards and compliance regulations

    Other automated processes should be introduced into the development cycle, including environment provisioning, data or API mocking; builds management; and standards enforcement. For instance, automated deployment solutions give DevOps a repeatable process so engineers have more time to focus on crafting new features. Another example is release automation tools that manage workflow as software moves between development, production and testing. These tools not only speed up the process, they also eliminate potential for human errors.

    The modern business relies heavily on applications to communicate, complete sales and operate more efficiently. Companies strive to bring these apps to the market quickly so they don’t miss opportunities and can adjust to market conditions. To accomplish these goals, companies must adopt the right software development processes and tools to improve their time-to-market speed and capture a competitive advantage.

    About the Author / Ajay Kaul

    Ajay Kaul is managing partner at AgreeYa, bringing more than 27 years of experience in sales, consulting and managing small to large IT projects worldwide. Kaul has led AgreeYa through 16+ years of success, leading the company in highly competitive and complex markets and driving significant profitable growth with global workforce of more than 1,500. Prior to founding AgreeYa, he was responsible for managing engagements for Deloitte serving private and public sector clients across United States. Connect with him on LinkedIn.

  • All Day DevOps: System Hardening with Ansible

    All Day DevOps: System Hardening with Ansible

    The DevOps pipeline is constantly changing.  Therefore, relevant security controls must be applied contextually.

    We want to be secure, but I think all of us would rather spend our time developing and deploying software. Keeping up with server updates and all of the other security tasks is like cleaning your home: you know it has to be done, but you really just want to enjoy your clean home. The good news is you can hire a “service” to keep your application security up to date, giving you more time to develop.

    At the recent All Day DevOps conference, Akash Mahajan (@makash), a founder/director at Appsecco, discussed hardening your system’s security with Ansible. In addition to his role at Appsecco, Akash is involved as a local leader with the Open Web Application Security Project (OWASP).

    Misconfiguration

    During his presentation, Akash mentioned the OWASP Top 10 Security Vulnerabilities list, zeroing in on No. 5: Security Misconfiguration. To determine if you comply with the guidelines, No. 5 on the list asks:

    • Is any of your software out of date?
    • Are there any unnecessary features enabled/installed including ports, services, accounts, pages or privileges?
    • Are default accounts and their passwords enabled/unchanged?
    • Are security settings and libraries not set to secure values?

    I am sure no one reading this article still uses the default administrator password, but can we say the same of your peers? Have you gotten around to installing the latest software patches on your server?

     

    Automation

    If a task can be automated, developers automate it. So we should automate our security tasks too, where we can. OWASP provides guidance here, suggesting you should:

    • Have a repeatable security hardening process.
    • Ensure your development, QA and production servers are configured identically but with different passwords.
    • Automate the process to minimize the effort required to setup a new secure environment.
    • Implement a process for deploying all new software updates and patches in a timely manner to each deployed environment.
    • Run scans and audits periodically to help detect future misconfigurations or missing patches.

    This is all part of security hardening, which is, “the process where we identify default configuration present on a system and apply changes that will change the configuration to secure values.” This can be applied to your network, transport, application, and kernel networking parameters.

    Ansible Playbooks

    Ansible is one of the solutions Akash likes to work with, but there are others solutions on the market that provide similar value. Without trying to endorse or evaluate one solution over another, let me share perspectives from Akash’s experience with his toolset.

    Why does he like it? It boils down to playbooks. An Ansible playbook is a codified security document, allowing you to describe the desired state of a system, rather than the specific steps of how to get to that state. As Akash points out, things change—it is better to have the end state described rather than have to change commands when the system changes.

    Other advantages of playbooks include:

    • Playbooks are written in YAML providing us with structure that we can learn and train on
    • Playbooks are text files, so we can use Git for version control
    • Managing playbooks is just like managing any software project
    • Playbooks are infrastructure as code but for security
    • Playbooks consist of roles, a key aspect of security
    • Numerous playbooks are available as open source

    The bottom line is you can—and you should—automate your security hardening process. Your users and other stakeholders will thank you and, most of all, you will thank yourself because you can spend more time on the things you love to do.

    Ansible is just one example of a solution that can be used to automate your security tasks. If you want to know more, Akash goes into further detail on getting started with Ansible in his full All Day DevOps conference session (just 30 minutes). The other 56 presentations from the All Day DevOps Conference are also available online, free of charge here.

    This blog series is reviewing sessions from the All Day DevOps conference from November which hosted over 13,500 registered attendees. Last week I discussed, “DevOps at Massive Scale.” Next week, look for “Operationalizing a Red Team for Fun and Profit,” delivered by Intuit’s own Ian Allison.

    — Derek E. Weeks

  • Dispelling the Myths Around Continuous Testing

    Dispelling the Myths Around Continuous Testing

    You may have seen the term “continuous testing” and thought it was just the DevOps flavor of the month. Some might even think it isn’t part of DevOps or isn’t for cloud or hybrid cloud applications. Well, think again.

    As it turns out, there are a few more fallacies around the idea of continuous testing floating around the application development community. Ready to find out?

    Chapter five in the new, free eBook “Continuous Testing for Dummies, IBM Limited Edition,” lists 10 myths. Here are a few to ponder:

    Continuous testing is only about executing test scripts

    Limiting the term “testing” to only the execution of test scripts is a misnomer. As my co-author, @Al_Wagner and I point out, testing and checking application functionality are not equal. There’s a long list of testing items to check off one’s list, the least of which is collaborating.

    Continuous testing is merely a buzzword

    Guess what? It’s a core part of that essential DevOps practice, continuous delivery. And, with customers demanding higher quality software faster, it isn’t going anywhere soon. In short, invest in continuous testing.

    Only agile teams do continuous testing

    False! Some or all parts of continuous testing are critical for any type of team as well as all players. This includes test automation, production-like test environments and realistic test data. A related myth—only testers contribute to testing—is also not true at all. The idea of continuous testing includes all team members. The book describes the roles everybody has to play. For example, did you know that designers can improve testing? They can work with testers to help them understand where the fragile parts of the application are.

    Automating tests means we need fewer tests

    No, the machines are not taking over. Automating tests does not mean cutting back on testing jobs. To the contrary, automation is reducing testers’ needs to act like cyborgs and spend more time doing what they do best: learn and experiment.

    Continuous testing isn’t for large, complex systems

    Au contraire! The best thing you can do for large or complex systems is leverage continuous testing practices and tools such as service virtualization to conduct end-to-end testing earlier and more frequently, rather than having each subsystem do all its own testing in isolation until just before deployment to production.

    To read more myths about continuous testing, check out “Continuous Testing for Dummies, IBM Limited Edition,” here.

    About the Author / Marianne Hollier

    MarianneMarianne Hollier is an IBM and Open Group Master Certified IT Specialist in application development. She has strong, practical expertise in measurably improving the software development life cycle and driving the necessary cultural changes to make it work. She is instrumental in architecting, tailoring and deploying the IBM DevOps best practices as well as appropriate software development tools on many types of projects, from large to small, long to fast-track, agile to traditional. Marianne is especially passionate about all things testing—process, tools, culture and automation. Her experience is broad-based, spanning both custom projects as well as standard software packages that apply to many industries, including refining, pharmaceutical, telecommunications, health care, financial, automotive, government and retail. Connect with Marianne on LinkedIn or Twitter.

  • Be Here Now – Agile and DevOps in the Current State of Synergy

    Be Here Now – Agile and DevOps in the Current State of Synergy

    If there’s one thing that our culture does not lack, it’s a litany of pithy catch-quotes meant to remind us to focus on the task at hand; yet, this often runs counter to our tendency to fixate on matters of the past and future.

    While we are so often encouraged to “live in the moment” and “seize the day”, this is hardly an easy task, especially as related to any sort of emerging phenomenon that compels us to improve on historical missteps, and predict how things should change for the better.

    Register today for the 3rd Annual DevOps Virtual Summit.

    With the methodologies of agile and DevOps the tendency is, of course, to do the same, harping on the inefficiencies of previous software delivery models and painting an elaborate portrait of how related workflows are being transformed overnight.

    The simple truth is that it’s easy to get excited about concepts that hold such tremendous potential in recasting an increasingly critical vital set of processes, and lose track of where things actually stand.

    To note, while a recent research project published by Coleman Parkes found that over 80 percent of organizations have adopted some manner of agile and DevOps practices, and see them as critical in transforming their internal software factories, only a third have adopted the methods on a broad scale.

    Point being, we’re still pretty early.

    That said, we in the business of helping organizations adopt related culture and tooling have gone to great lengths to encourage everyone that this change should be pursued with dogged intensity. We have sliced and diced the data to illustrate how those organizations at the forefront of so-called digital transformation, enabled by agile and DevOps, are realizing the results in the form of increased velocity.

    The same research finds that “advanced” adopters of the two concepts are, in fact, seeing significant improvement in time-to-market, customer satisfaction and new business growth.

    But research is just that, and often not completely aligned with real-world scenarios. Someone who takes the time to answer a survey about such matters, one could reasonably expect, is the type of person far more likely to be involved in agile and DevOps activities.

    My personal conversations with everyday practitioners [aka other parents on the sidelines at my kids’ sports and social events, many of whom work in IT] tell me that we’re much more oriented to the “pockets of innovation” phase at present, than any sense of pervasive adoption.

    So this begs the two-part question – where do we really stand, and what do I really need to care about?

    The only reliable source of record in my mind is the perspective of people already doing the work, beyond what I can discern amid basketball games and middle school theater. Real-world practitioners are the voices of reason that allow us to “be here now” and address the specifics of practical agile and DevOps implementation.

    Over the past several years, I’ve found one of the best sources of such input to be the customer panels available at industry conferences and on webcasts. When it’s time for me to sit down and crank out some related content, I often go back to these recordings to remind myself where the rubber actually hits the road.

    On Tuesday Mar. 7, we’ll host just such an event, the 3rd Annual DevOps Virtual Summit, where agile and DevOps leaders from organizations including CNN, GM Financial and United Airlines will share their thoughts on how this ongoing transformation is playing out, and where the remaining challenges lie.

    Along with those experts, we’ll also hear from Dr. Nicole Forsgren, one of the leading researchers in the space who is in seemingly constant contact with people leading the charge and working in the trenches putting agile and DevOps into practice.

    As a marketer, and previously as a journalist, everything that I know comes from direct interaction with those colleagues willing to share their hands-on experience garnered via doing this work every day.

    Register for the event and join us to find out where agile and DevOps actually stand today.

    — Matt Hines