devopsy.kinsta.cloud

Category: DevOps Practice

  • 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

  • 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

  • Speed NPM Releases and Gain Confidence Using an NPM Registry

    Speed NPM Releases and Gain Confidence Using an NPM Registry

    Building applications in the NPM development life cycle can be very complex. Let’s review the main factors that contribute to this complexity:

    • An endless number of variables: Building applications involves a huge number of variables. Not only are there locally installed dependencies in the package.json (which should use absolute versions for each dependency), but there are also environment variables and global system settings.
    • Different environments across multiple builds: It can become impossible, especially in larger projects, to maintain the same environment between builds. Even if the same host is used for both builds, local system changes between builds can have a dramatic impact on the published packages. In addition, having a master-slave continuous integration (CI) process further complicates this problem.
    • Lack of trust in your binaries: When you pull an internal package in an application, you need to be confident that the binary you are using has been thoroughly tested. Otherwise, it will be the first thing you’ll be blamed for when their project fails.

    In this blog post, I will show you the best practices to apply during the npm build process by using an npm registry to ensure that the same binary passes QA and makes it to the production repository.

    Streamlining Your NPM QA-to-Release Pipeline

    You need to have the following set up prior to creating your streamlined pipeline:

    • A repository manager recommended for binary management.
    • An automated build server, for example, Jenkins.
    • Staging and release environments to be configured as site hosts similar to the production environment, where automated load and quality tests can be performed as per your QA team’s requirements.
    • An npm project.

    Stage 1: Software development

    During the development process, run an automated QA cycle to ensure that the binary qualifies this stage.

    Stage 2: Source code deployment

    In this stage, complete the function and merge it to your Git branch. This triggers the Jenkins npm install to build the package.

    Stage 3: CI server pulls dependencies

    The CI server pulls the dependencies when you run ‘npm install’ command.

    Note: To simplify the project, use a Binary Repository Manager to store the exact binary dependencies used in the project.

    Stage 4: Deploy the Binaries to the target binary repository

    Running the ‘npm deploy’ command causes the CI server to deploy the produced binaries to a target binary repository manager repository.

    Note that at this stage, the binary is untested and is tagged as a “snapshot” build. As the package is untested, it should be moved to a non-production “snapshot” or “staging” repository where developers can use these packages at their own risk.

    Stage 5: Run a second cycle of automated QA on the package

    I recommend performing a second round of automated QA in addition to the development stage to ensure that package passes this stage.

    If the package passes the above tests, it qualifies to enter the staging environment. The same package is “promoted” from snapshot mode to staging. After the app successfully meets the intended basic functionality, it can be deployed to the staging environment.

    Stage 6: Deploy the package to a staging environment

    This is typically where the development split occurs happens.

    A common bad practice would be to rebuild the application after it passes QA, producing a new binary that differs from the original package.
    I recommend using the same .tar.gz when promoting to later build steps.

    Perform any QA scripts, which may differ depending on the project. The tests running in the staging environment should closely reflect the real environment. This can also include beta and manual testing.

    Proceed to move the pulled binary “Staging” repository.

    Stage 7: Deploy the package to a release repository

    Once again, it is bad practice to rebuild the same package using the same source code but in a different environment during this phase.

    The intended developers, who will eventually be using this package, need to be sure it is the same package that has passed the entire round of testing. Otherwise, you will be the one to blame if their application fails because of using this package.

    Hurrah! Your npm registry is up and running.

    The npm registry DevOps pipeline is now simplified by using the same binaries during the entire process. To conclude, these are the best practices that are recommended to follow when creating your npm registry:

    • Ensure the exact same binary that was built makes it through the entire process.
    • Instruct project developers to provide meaningful names to repositories. For example: “Snapshot” = Untested.
    • Do not re-upload binaries that have been tested. Testing can modify the underlying binary and have unexpected changes.

    Try creating your own npm registry using my customized projects as an example framework:

    — Patrick Russell

  • A Right DevOps Approach: Assess Organizational Readiness

    A Right DevOps Approach: Assess Organizational Readiness

    Driving business in this fast-paced world is maddening as owners have to remember customer preferences, beat market competition and similarly cater to different things within the organization’s radius.

    How a business owner manages all this defines the business success, which is gauged through outcomes in the form of smart products, point-on services and almost-immediate feedback. Bank applications, the best smartphones and interactive technology are all proof of this.

    But what is it that stands at the heart of it all?

    The Right DevOps Approach

    When enough is done and businesses still find that there’s a missing piece that will complete “the successful business picture,” they go back to figuring out what and how they can fix the problem. They never come to realize that they will have to consider revamping their organizational structure to meet the growing demands of their influential business.

    How, then, do you assess your approach to DevOps?

    While most believe that it’s a technological approach that they should incorporate in their business, it’s more of a cultural approach. To implement DevOps into your existing organizational structure, you first must look at its current state of readiness.

    Doing this is important, as it helps decision-makers understand how they can embed the smart collaboration after a thorough consideration of the challenges that stand in the way of DevOps implementation. Once the initial assessment is done, business owners need to ask themselves three questions before assessing DevOps readiness:

    1. Is there a Management-Employee Agreement? A successful DevOps process not only relies on collaboration between Development and Operations, but also needs a top-down (management-employee) agreement. Once that’s in place, the company is already halfway through the success road.
    2. Is there a Plan in Place? Many firms just barge into technology like it’s all they need to reach their finish line. Stop! Wait! Think! Owners need to have a detailed strategy, equipped with process tools and goals clearly outlined and best practices chalked out. Once this is done, the culturally different teams need to collaborate and work ways to learn and equip themselves with the technologies and practices of each other’s processes. With all this in place, organizations will be ready to take the DevOps jump.
    3. Is the Organization Ready to Tread the Ocean? Now that the plan is in place, what’s next? Organizations, as mentioned earlier, are in hot pursuit to experiment with what they’ve learnt new. Anything new is fancy, but humbleness is the key! Starting small will set the new cultural shift to completely settle in its new mold. To run the boat in big waters, you first need to test it in small water. Similarly, to test the success of DevOps for a big business project, you first want to test its adaptability to a smaller one. Once you’ve cut off from the harbor, you are all set to wade the ocean.

    Conclusion

    Most business players underestimate the ability of DevOps with whatever industry rumors they hear and some of their own pre-conceived notions. Some other think that they know it all, but what matters is having a strategic approach to first considering DevOps and its tools, and then adapting it accordingly.

    Once the DevOps automation is in place, organizations will be busy reaping the benefits of its successful implementation.

    — Veritis

  • How Can DevOps Enable Your Software Testing efforts?

    How Can DevOps Enable Your Software Testing efforts?

    Changing market dynamics are pushing the need to include DevOps in your software testing exercise to help meet business objectives in providing a consistent and flawless user experience.

    Digital transformation is not an easy task for business enterprises. There are myriad issues to conquer, such as department silos, legacy systems and a well-entrenched work culture that often refuses to align with the business goals. Needless to say, the imperatives of reaching out to the market quickly and with quality products often are not achieved because of these issues. To eliminate the bottlenecks that end up blighting business enterprises, a growing number of organizations are adopting DevOps, which involves an end-to-end automation of processes, be it for development, testing or deployment.

    DevOps takes the Agile methodology a step further by involving all the stakeholders of an enterprise. The DevOps testing strategy encompasses continuous improvement of software products to address the changing customer preferences.

    In DevOps software testing, the aim is to detect and eliminate glitches proactively to reduce the cost and time to fix issues that can lead to a poor user experience. In the highly competitive digital market, a poor user experience can stymie a business’s market readiness.

    However, businesses should realize that the DevOps software testing approach is a journey and should be leveraged to enhance the user experience on a continuous basis.

    What’s the Key Value Expected from DevOps?

    Considering that the development and operations teams of an enterprise each have different work cultures, systems, goals, tools and approaches, the quality and delivery schedule of applications can be thrown off. Hence, the significance of DevOps testing strategy comes into play to bring synergy between the teams and to enhance the quality and delivery of applications consistently.

    DevOps calls for the integration of development and operations teams, wherein QA is made everyone’s responsibility. The synergy helps in breaking the departmental silos and posits the role of QA as an enabler of value addition and to achieve customer delight. This not only ensures quality, but also enables faster turnaround on application development process. Ultimately, enterprises are better equipped for the changing market dynamics and challenges with their business applications.

    Key Drivers to Adopt DevOps

    George Spafford, research director at Gartner, said:

    “A DevOps initiative must focus on business requirements and not on ‘doing DevOps for the sake of DevOps,’ wherein the methods and tools become more important than what customers need. Organizations must avoid the all-too-common mistake of launching a DevOps initiative before establishing that a business reason exists to do so. For example, instead of focusing on release rates and doing things faster, start with the business value by asking what that will enable.”

    Hence, it’s important to work with a DevOps strategy that resonates with the business objectives. These are some key drivers for considering DevOps.

    • Quick deployment of quality applications across devices, platforms, operating systems and networks.
    • Increasing competition necessitating the faster release of apps.
    • Emerging technological platforms whetting the appetite of customers for better products.
    • The emergence of complex applications with footprints in the physical and virtual world.

    How Does DevOps Enable Effective Quality Assurance?

    • It makes QA a collective responsibility rather than being assigned to a single department or organization.
    • It enables better collaboration between teams through a shift of culture.
    • It ensures faster identification and elimination of glitches.
    • It is responsible for accelerating the time to market and keeps a tab on the software quality through customer feedback.
    • It provides continuous improvement of software through timely releases.
    • It reduces cost due to the absence of rework.
    • It optimizes the utilization of resources and prevents waste.
    • It helps to cut down the software development life cycle (SDLC) by adopting quick sprints.
    • It ensures continuous development, testing, integration, deployment, monitoring and innovation of applications.

    The Need to Measure DevOps

    Digital transformation has necessitated the need for rapid innovation, development, testing and deployment of applications. Post deployment, appropriate customer feedback should be considered and absorbed into the product to improve its performance further. The success of DevOps QA depends on the level of automation, not to speak of the degree of collaboration among various stakeholders.

    In fact, enterprises should use a robust automation software to execute quality assurance across platforms and devices. The automation software should be able to test the code as part of the development sprint on a variety of devices and test environments. The DevOps QA approach should be measurable based on certain metrics to ensure its effectiveness. The measurement platform can include the following:

    • The QA team dealing with continuous integration should be able to work with all the tools to find out glitches.
    • The entire setup should be simple to facilitate quicker learning, adoption and execution.
    • The test data including dependencies should be easy to access.
    • The entire build, deploy, release, verify and rework processes should be streamlined.

    Conclusion

    In the fast-changing digital landscape, the objective of reaching out to the customers quickly and with better quality of products is paramount. This is where the DevOps specialists turn things around with continuous improvement, innovation and deployment.

    As Gartner’s Spafford rightly stated, “DevOps challenges conventional IT thinking with its lack of a standard definition and approach, its constant evolution, and its requirement for acceptance and management of risk.”

    — Komal Lopez

  • Siemens Acquires Mendix to Advance Low-Code Platform Adoption

    Siemens Acquires Mendix to Advance Low-Code Platform Adoption

    Siemens this week moved to substantially accelerate its transition into becoming a software company by acquiring Mendix, a provider of low-code application development tools, for $730 million in cash.

    Mendix CEO Derek Roos said Mendix will operate as a business unit of Siemens, which has poured more than $10 billion over the last decade to software development as part of an ongoing digital transformation to a multibillion-dollar conglomerate.

    Siemens over the last year determined that Mendix was now a strategic component of that initiative, Roos said, as more applications are shifted to and developed in the cloud. Many Siemens employees already use Mendix tools to develop custom applications with limited to no programming skills. That capability is especially critical in line of business (LOB) organizations that are starting to deploy their internet of things (IoT) applications, he noted. Mendix also recently revealed it is starting to infuse its low-code application development platform with artificial intelligence (AI) capabilities.

    Roos said the $730 million investment Siemens is making to acquire Mendix is larger than all the venture capital investments made in rival companies delivering low-code platforms combined. As low-code tools have gained mainstream adoption, however, Mendix increasingly finds itself competing directly with larger rivals such as Microsoft and Salesforce, he noted.

    The Siemens decision to acquire Mendix comes at a time when archrival GE is throttling back on digital process transformation efforts. Roos said GE’s decision is unique to structural issues within GE versus being a decision that reflects loss of faith in digital process transformation driven by custom application development. Software is now the fastest growing segment of the Siemens conglomerate, he said.

    A recent survey conducted by Mendix in collaboration with ASUG, an end user association for organizations that have deployed software from SAP, finds 64 percent of respondents are experiencing increased demand for custom applications within their organizations. The primary problem is that same survey finds the average custom application development backlog is 24 months. Primary issues cited by survey respondents include high development costs (50 percent), difficulty integrating with existing systems (47 percent) and lack of skilled development resources (45 percent).

    Of course, as Siemens becomes a larger software force, some organizations will start will take into consideration how much they may compete with the company before selecting an application development platform. Mendix is betting that as application development expands well beyond internal IT organizations, its status as an independent business unit of Siemens will provide enough distance between Mendix and Siemens business units that a Mendix customer might compete against.

    In the meantime, organizations that are embracing low-code platforms are simultaneously increasing their investments in DevOps processes. As the number of applications being developed using low-code tools increases, there is a corresponding increase in application release management that requires them to modernize those processes. As Mendix plays the role in enabling applications that can be deployed from the cloud to the network edge, it’s now only a matter of time before the Mendix low-code platform becomes a more significant element of a larger set of DevOps processes driving digital process transformation projects as unprecedented levels of scale.

    — Mike Vizard

  • Accenture Aims to Infuse AI into App Testing

    Accenture Aims to Infuse AI into App Testing

    Accenture plans to infuse greater amounts of artificial intelligence into application development testing following its acquisition of Real Time Analytics Platform Inc., which provides tools that make use of machine learning algorithms, neural networks and natural language processing (NLP) to analyze every stage of the software development life cycle.

    Kishore Durg, senior managing director and growth and strategy lead for Accenture Technology, the IT services arm of Accenture, will incorporate the AI technologies developed by Real Rime Analytics Platform into the Accenture Touchless Testing Platform, which is a suite of open source and proprietary testing tools that Accenture has infused with advanced analytics and cognitive computing technologies.

    Durg said Accenture is committed to automating application testing using AI technologies to help organizations increase the productivity of application development teams. At a time when organizations are investing in a broad range of digital transformation projects, the rate at which applications can be built, tested and deployed has become a critical issue.

    Most organizations on their own won’t be able to aggregate enough data to drive machine learning algorithms and neural networks to drive a meaningful AI model. Those models require access to massive amounts of data to be trained to identify potential issues within any application. Because of the size and scope of the projects Accenture works on, organizations that employ its service can benefit from all the data that Accenture can bring to bear to train AI models, Durg noted.

    The quality of the data used to train those AI models is also as important as the amount of data, added Durg. Accenture has the resources required to cleanse data before it gets fed into an AI model, as well the expertise needed to eliminate any biases that might get built into any algorithm being applied to that data, he said.

    As AI continues to evolve, it won’t be long before every application incorporates some form of an AI model. Each of those models not only needs to be trained, but they also need to be updated continually—and eventually replaced by more sophisticated models as more data becomes available. In effect, that requirement will create a need to extend DevOps processes to how AI models are incorporated within an application.

    At the same time, it’s clear that large swaths of DevOps processes involving, for example, application testing can be increasingly automated using a variety of machine learning and network networks, also known as deep learning algorithms.

    In theory, that should accelerate the rate at which applications are developed and deployed, while testing processes that are augmented by AI technologies should result in applications that are more secure, as many more vulnerabilities will be discovered long before an application gets deployed in a production environment.

    In fact, the inclusion of advanced algorithms across a DevOps toolchain might accelerate adoption of DevOps processes. After all, most IT organizations today have embraced DevOps unevenly largely because of the complexity involved. AI technologies one day soon may eliminate that issue altogether.

    — Mike Vizard

  • Can You Implement DevOps in Large Organizations?

    Can You Implement DevOps in Large Organizations?

    Trying to modernize workflows through DevOps can be a challenge for any company, but there are different challenges, risks and benefits for bigger companies

    It is now more or less standard procedure to implement DevOps principles in startups or smaller companies. But what if you’re trying to utilize DevOps in large organizations? This is a bit more challenging, but let’s take a look at how such enterprises might approach a DevOps transformation through a few of the core tenants of DevOps.

    Rapid Feedback

    There are different types of feedback that come with DevOps: automated feedback about specific code (typically through unit and integration testing software), personal feedback from other team members, consumer feedback from customers using your product and cross-team feedback throughout the organization. Startups and small companies may find it easier to have open lines of communication between individual team members as well as across teams.

    Large organizations will need to make a conscious effort to keep team communication open. On the other hand, they will have more resources available (both money and employees) to field customer and in-house feedback about individual services or larger products. They may also be able to better purchase and implement automated testing and CI/CD tools, which leads to …

    Automation

    One of the biggest tech benefits to a DevOps approach is automating away the manual tasks that bog down critical projects. Large organizations often have the time, money and people to set up automated tools, such as CI/CD pipelines, unit and integration test suites and config management systems. The biggest challenge in the enterprise world is trying to make everyone happy.

    One approach is to standardize on a single tool for each purpose, such as Jenkins or Chef. This can enable your IT staff to specialize in those tools but may make some users unhappy with being forced into a tool they may not prefer. The alternative is to allow each team or business unit to use their own preferred software, but this can turn into a “toolset hell” with a mashup of every combination of applications within your organization. Each approach has its pros and cons, and often comes down to a management decision.

    Eliminating Silos

    Having individual teams that handle their part of the puzzle and nothing else is the biggest hurdle that enterprises face when trying to apply DevOps principles. The combination of “dev” and “ops” (and other disciplines, such as “sec” and “fin”) is naturally split out in a large organization, so recombining them can be a huge undertaking. Then again, that gap is exactly the problem the DevOps approach seeks to solve.

    Some companies solve this by having a separate team that handles the cross-team support and communication. Other companies break down these silos by enabling employees to migrate seamlessly between teams depending on the project or application. The more “DevOpsy” method is to utilize ChatOps and centralized documentation repositories for open communication and collaboration, which can help break down unify the distinct teams.

    Holistic Thinking

    The idea of holistic thinking tends to come easier to larger organizations, as successful enterprises typically have a system in place for “big picture” thinking, either through a management or product team, or through a cross-functional committee. That said, communication of this vision down to the employees, along with communication up to that management team, is crucial for enabling outside-the-box thinking to get past any roadblocks and hurdles that are in the way of creating and deploying the end product. Sometimes, the hardest part is convincing programmers that not everything needs to be solved with code!

    DevOps in Large Organizations: Challenging but Rewarding

    Some folks think that DevOps only applies to startups and small companies, but we’re seeing more and more teams benefit from implementing DevOps in large organizations. The benefits of the above DevOps principles are numerous, but frequently come with a different set of challenges based on your organizational size. Once you are aware of those challenges and have a plan to overcome them, you can start to transform your enterprise to a DevOps shop.

    — Jay Chapel

  • The Software Testing Metrics That Make Or Break DevOps Success

    The Software Testing Metrics That Make Or Break DevOps Success

    Organizations today are racing to develop software at a breakneck pace through efficient DevOps processes. But it’s important for them to avoid losing sight of the forest for the trees. If too much of that speed comes with quality sacrifices that degrade the user experience, the rapid software iterations hurt the business more than they help it.

    “Organizations adopt DevOps to accelerate the delivery of innovative software that creates positive user experiences,” said Clark Golestani, former CIO at pharmaceuticals giant Merck and current managing director of C Sensei Group. “If you start accelerating delivery without also rethinking your approach to quality, you will end up rapidly delivering updates that drive your customers to competitors.”

    This is why continuous and automated testing is so essential to DevOps success. But instituting effective and streamlined testing is easier said than done. Organizations must continually tweak what, how and when they test their software to achieve the optimal test coverage while introducing as little friction as possible into the software delivery pipeline. It’s a delicate balance, and the only way to achieve it is to keep meticulous track of metrics that evaluate how well the testing process is improving quality throughout the development life cycle.

    “As the saying goes, ‘You can’t manage what you don’t measure,’” said Andrew Magarie, senior market impact consultant at Forrester Consulting. “So firms need to be able to define and track the right metrics that can help enable quality at speed while minimizing risk.”

    Magarie and his team at Forrester recently conducted research into 94 different quality metrics frequently measured by DevOps organizations across four development stages: build, functional validation, integration and end-to-end regression testing. The study showed that the most effective test metrics that bubbled up across all of stages tended to clump into at least one of three categories.

    Risk-Focused Metrics

    According to Magarie’s report, the most mature and effective organizations fundamentally chose testing metrics that best helped them understand business risk posed by the software throughout the development process.

    “For this study, we use the following definition of business risk: Any application shortcoming that impairs the end user’s (or customer’s) expected experience and ultimately erodes confidence in the business,” he explained.

    For example, during the build stage mature organizations consider measuring the number of automated tests prioritized by risk as one of the most important assessments.

    “Tracking ‘unit’ tests prioritized by risk is the key. As the code base evolves, developers and testers need immediate feedback about change impact. This feedback is significantly more actionable if prioritized by level of risk,” wrote Magarie.

    As he explained, business risk will be different for every application, and the complexity of an organization’s architecture and transaction dependencies adds more variables to the equation. However, organizations need to seek ways to measure ‘relative risk’ across the software development life cycle (SDLC) if they truly want to take a disciplined approach to incrementally improving quality in their software.

    Contextual Metrics

    Forrester found that simple “counting” metrics don’t offer QA nearly as much value as contextual metrics. So simply tracking the number of tests will not provide teams with as much actionable data as the measurement of the ratio of requirements covered by tests. Approximately 69 percent of mature organizations say running functional tests and checking against covered requirements is a top measurement and 75 percent say the same about API tests run against functional requirements.

    Holistic UX Metrics

    The most mature organizations recognize that while application-specific or team-specific QA metrics are important, the ultimate goal is ensure the quality of the user experience (UX) across their entire interaction with an application. This means measuring the thoroughness of end-to-end regression testing is crucial. Approximately 70 percent of leading DevOps organizations say they believe the percent of automated end-to-end test cases as a top metric.

    — Ericka Chickowski

  • 9 Ways DevOps Success or Failure Is Like Baseball

    9 Ways DevOps Success or Failure Is Like Baseball

    The baseball season is in full swing. There are 30 major league teams competing for a playoff spot, but, as I write this, only five of them—or 16.67 percent—qualify as elite performers with a winning percentage over .600.

    The number is strikingly similar in DevOps, where, according to one survey, just 17 percent of organizations say they have fully embraced it. Most of the rest have only scattershot teams immersed in DevOps or only recently began adopting it company wide. Fifteen percent are saying, “Wait ’til next year” and have yet to undertake this agile methodology.

    In baseball, teams struggle because of weak hitting, lousy pitching, poor defense, inept managing or all of the above. But why do some DevOps initiatives fail, who is at fault and what can be done to right the ship?

    Baseball and DevOps: More Similarities Than Differences

    Let’s dissect the differences between a DevOps program that hits the ball out of the park with a truly collaborative effort to build, test and release software faster and more reliably, and one that swings and misses.

    Is It Understood There’s No “I” in Team?

    Most DevOps initiatives fail because they are undertaken by a single practitioner within a single team. This is a strong personality who bulldozes the team to DevOps success, either out of career growth ambitions or genuine belief in DevOps tenets, only to have the team revert to their old ways when the practitioner leaves.

    Ironically, many if not most successful DevOps initiatives also begin with a practitioner on a single team. The difference in the latter case is that the leader doesn’t operate in a vacuum but shares lessons and best practices across the organization. They understand that if you are going to do something transformational, you cannot do it in the shadows or within a silo. They consider the long term. They lead by example and demonstrate the way forward to others.

    Are the Top Leaders Onboard?

    Just as the best baseball teams tend to have smart, supportive, quality-minded owners, the most successful and sustainable DevOps initiatives have top-down leadership support or mandates.

    Clear, consistent direction from the C-suite is necessary to motivate and incentivize people across the company and move DevOps initiatives from a patchwork of projects to an organizationwide philosophy.

    “Without executive support,” a Forrester report warns, “agile transformation is limited to grassroots initiatives—a very slow and difficult road.”

    Are the Danger Signs Recognized?

    There are two telltale signs that a companywide program is floundering. One, success is occurring only in a single team. Two, no one outside the team knows much or anything about that success. DevOps can’t grow within an organization if it’s an isolated black box.

    Starting DevOps is kind of like an entrepreneurial act. Startups become something bigger when the entrepreneur is successfully able to extend their vision. DevOps is the same: You need to infect other teams with your success. Winning begets winning.

    Another indicator of failure is if a company claims to be adopting DevOps but clings to traditionally organized and siloed teams. You can’t have it both ways. DevOps personnel need to be aligned by product, outcome or value stream—not by specialized work function.

    Is Success Measured?

    How does a baseball team know it’s winning the game if no one is keeping score? Same in DevOps. If you can’t objectively measure success, you don’t know if your program is meeting its goal of accelerating the software life cycle.

    Figure out how to measure the value of what is being done and delivered now so you can demonstrate its impact objectively. Examples could be application deployment frequency and time, error rates and mean time to detection.

    Is Seeking Outside Help a No-No?

    The DevOps community isn’t especially fond of vendors and consultants, but outside experts can bring fresh perspectives. No one tries to cure an infection or solve marriage issues by themselves, and solving DevOps challenges should be no different. Don’t be afraid to ask for help and if you have the budget pay of it.

    Can the DevOps Advocates Speak Business Language?

    DevOps folks often stumble when pitching for leadership support because they are unable to articulate their proposals in the dollars and cents language that business leaders understand. But if they can talk that way, practitioners may find leaders are much more willing to play ball than they realize.

    Is the Blame Game in Fashion?

    The biggest mistake organizations can make is bearing the classic IT coat of arms: arms crossed and fingers pointing. Don’t fall into the blaming trap. DevOps, after all, espouses the concept of learning from failure. So instead of pointing fingers, evaluate, consider, learn and move on with the lessons learned.

    As legendary New York Yankess manager Casey Stengall said, “All blame is a waste of time. No matter how much fault you find with another, and regardless of how much you blame him, it will not change you.”

    Does Failure Breed Success?

    Not to sound harsh, but if you start an initiative and it fails, it is your fault. Sure, many company cultures aren’t ready for DevOps, but others are succeeding where you have failed. If your team lost the World Series, another team won it. Why? There is always something that can be done differently. Determine what went wrong, accept responsibility and learn from it.

    Do People Bounce Back?

    If your initiative wasn’t successful, don’t be discouraged. Pick yourself up and try again. Being a DevOps leader requires courage and persistence. You’ll get ‘em next time.

    “Every day is a new opportunity,” Hall of Fame pitcher Bob Feller said. “You can build on yesterday’s success or put its failures behind and start over again.”

    — Scott Willson