Category: DevOps Toolbox

  • Oracle Launches Managed JSON Database Service

    Oracle Launches Managed JSON Database Service

    Oracle today unfurled as standalone Autonomous JSON Database service that it will manage on behalf of developers that require a document database.

    Gerald Venzl, a developer evangelist and distinguished product manager for Oracle, said the Autonomous JSON Database service is based on support for JSON data types that Oracle currently provides in its Autonomous Database service based on its relational database.

    Priced at a quarter of Oracle Autonomous Database service, Oracle is also targeting rivals such as MongoDB by also pricing Autonomous JSON Database service at roughly 30% less than rival managed database service, Venzl noted.

    In addition, because Autonomous JSON Database service is based on the same platform Oracle employs to deliver its Autonomous Database Service, developers can add support for a wide variety of other data types by upgrading to the Autonomous Database Service with a single click, added Venzl.

    That approach provides developers with more flexibility should their data requirements change, or they simply initially chose the wrong type of database for their application, said Venzl.

    Other capabilities provided by the Autonomous JSON Database include support for built-in machine learning algorithms and spatial queries; fine-grained access controls; a server-side procedural language; low-code development tools; support for ACID-compliant transactions with no time or transaction size limits, support for cross-collection joins and/or aggregations and a search index for JSON documents.

    Oracle also makes available an open source document store application programming interface (API) dubbed Simple Oracle Document Access (SODA) that makes it simpler for developers to employ programming languages such as Java, JavaScript and Python to build applications on top of a JSON data store. Autonomous JSON Database stores JSON documents in a native tree-oriented binary format that Oracle claims is optimized for fast reads simplified updates.

    It’s not clear to what degree IT organizations will embrace managed database services. Oracle is making a case for managed database services that essentially eliminates the need to rely on database administrators to manage the infrastructure the database is deployed on as well as any upgrades made to the database itself.

    Developers in recent years have embraced document databases in part because they are easier for them to provision. In most cases, developers download a document database that they at least initially manage themselves. The challenge IT organizations inevitably encounter is the number of document databases that need to be supported grows rapidly. Developers who are focused on building applications don’t always have the time required to manage fleets of databases.

    Oracle is, of course, making a case of managing a variety of classes of databases. As enterprise applications continue to evolve in organizations the number of data types organizations are supporting continues to expand. A managed service focused on only one class of database may not be as appealing as a suite of managed service options.

    Regardless of approach, it’s clear database management is getting more automated. The opportunity and challenge now are finding the best way to incorporate database management with a larger set of DevOps practices.

  • Pushing Beyond Agility: The Kanban Maturity Model

    Pushing Beyond Agility: The Kanban Maturity Model

    Kanban is not a novel idea. It is a well-practiced and known method for organizations to increase productivity and efficiency, reduce the lead time of processes and improve delivery flow. However, historically Kanban has been frequently misunderstood.  Many people think that Kanban is just a whiteboard with stickies in columns of to-do, doing, and done. Or just a visual representation of a board in their agile tool. This resulted in many organizations missing out on the full potential of Kanban.

    The Kanban Maturity Model (KMM) is challenging this idea by defining certain steps for growing the maturity of the organizations that use the Kanban Method. The KMM collects and summarizes a decade of experience applying Kanban across diverse industries, in businesses of all sizes. By codifying these experiences, it addresses two common problems experienced in Kanban and agile implementations: overreaching and plateauing. We see overreaching when organizations or teams learn about some interesting practices and try to take them on before they are ready for them. While the practices have shown to be valuable in evolved environments, when taken on too early they can backfire. Plateauing happens when improvement levels off as the original problem that initiated the change initiative is abated. While there have been some improvements, there is potential for significantly more improvement. The KMM addresses this by identifying a road map and coaching tools for taking teams or an organization to the next level of improvement.

    As defined by Teodora Bozheva, Kanban trainer and consultant, and co-author of the “Kanban Maturity Model” with David J. Anderson, “The Kanban Maturity Model provides guidance for developing cultural values and management practices that enable enterprise agility, better customer satisfaction and business outcomes. It is an organizational maturity model that helps organizations evolve their agility and resilience.”

    The KMM maps Kanban practices as well as cultural values against seven organizational maturity levels. At first sight, the KMM may look complex. However, by advancing through the different stages, organizations are helped in a variety of ways with a road map to achieve their improvement goals.  For example, it can help relieve staff from overburdening, make processes more predictable and sustain a balanced workflow. In addition, businesses can deliver faster to market, align around a shared purpose and strengthen organizational values.

    When used in conjunction with software technologies such as Kanbanize, a Kanban automation solution for Agile Project Management, the model helps users fully optimize the workflow across all business functions and bolster the full intent of Kanban. Kanban software solutions and the KMM are stronger together. When companies simply invest only in Kanban automation solutions, they lack the required guidance and resources to fully maximize such tools. Similarly, without the automation of processes, insights and metrics provided by Kanban software technologies, deeper organizational maturity on the KMM scale is difficult to achieve.

    KMM: Understanding the Maturity Levels

    Transitioning from individual gain to the long-term company goals, each level represents a different step in the organizational journey toward agility with Kanban. The seven levels are arranged based on the company focus, main values, how stable the business is and what benefits it receives from Kanban. It is important to understand that each level of the model includes transition and consolidation practices. The transition practices are key to getting past the plateau and helping move from one level to the next,  causing the company to reflect on what can be improved in the process. The consolidation practices are then pulled to achieve the outcomes that the maturity level describes.

    Level 0 – Oblivious

    If your organization is not aware of the need for a structured work process, you are at maturity Level 0. Most organizations at this stage do not have a systematic approach to organizing the way they work and have a difficult time applying Kanban on a team level. At this stage, organizations typically visualize work on a personal level using either a physical or online Kanban board.

    Level 1 – Team Focused

    At maturity Level 1, team members already have built the habit of using Kanban on an individual level. After individuals start to recognize the advantages of simple workflow visualization, it is time to transmit the benefits of Kanban from an individual to a team level.

    An indication that an organization has initiated the transition toward using Kanban at the team level is that the work from the personal Kanban boards is moved to a shared team Kanban board using per-person swim lanes. This way, team members will easily recognize their own tasks, but at the same time, have an overview of what others are doing.

    An important step at this stage is to define and visualize initial policies. These are norms or rules that the whole team agrees to follow for the sake of normal functioning and improving work processes.

    Level 2 – Customer-Driven

    So far, your team should have an understanding that using Kanban helps to boost collaboration and bring transparency to the work process. The next step is recognizing the workflow. In other words, the team starts to understand what and how things are done and realize the need for a defined work process. The goal is for workers to understand what is expected of them and what they can expect of their colleagues with a shared vision of what finished product should look like.

    However, at this stage, while the process, policy usage and decision frameworks are consistent, there is still inconsistency of the desired outcome.

    Level 3 – Fit-for-Purpose

    By the time a company reaches maturity Level 3, they get a deeper understanding and better definition of their processes, workflow, policies and decision frameworks. It is important that the whole team agrees on all of them and understands how they help them achieve better results.

    As you start to outgrow maturity Level 2 and begin the transition from a customer-driven to a “fit-for-purpose” process, an organization becomes better at meeting customer expectations in a sustainable manner, as well as balancing upstream and downstream flow. The steps for maturity should be dedicated to complete alignment of the organizational requirements and processes needed to consistently meet customer expectations with predictability, a fast and balanced workflow, actionable metrics and shorter lead time.

    Level 4 – Risk Hedged

    Maturity Level 4 introduces risk-hedging practices, data-driven decision-making frameworks and use of predictive models. At this level, organizations embrace a model-driven management approach to strategic planning that anticipates risks, forecasts outcomes and results in consistent economics. All these improve overall business economics and robustness against unforeseen events and exceptional circumstances.

    Level 5 – Market Leader

    At maturity Level 5, not only have design, implementation and service delivery become routinely “fit-for-purpose,” the business is now entirely “fit-for-purpose” from a shareholder and end user perspective. The focus of this level is now on continually optimizing the workflow for efficiency and improved economic outcomes without sacrificing quality, increasing margins, minimizing costs and optimizing the value of work done.

    Level 6 – Built for Survival

    The deepest stage, maturity Level 6, is when a business can be established as “built to last.”

    The business is capable of questioning and assessing:

    • Is the way we do things still competitive?
    • Are new technologies, processes, methods or means becoming available that we should be investigating or adopting?
    • Do we offer the right products and services? and if not, how should we change?
    • Are we serving the right markets? Do we have the capability to serve our chosen markets adequately?
    • Who are we as a company? Is our current identity relevant and appropriate, or do we need to reinvent ourselves?

    These questions are strategic concerns, and the answers can help establish capabilities and services that align with the broader company strategy and bottom-line.

    A Road Map for Business Resiliency

    Over the past few years more and more people have learned, understood and applied the Kanban Method correctly and demonstrated significantly improved results. Knowledge work of all forms, from operations to project management to product innovation, the use cases and impact of Kanban across industries and business functions are extensive but sometimes underutilized. The KMM provides a greatly detailed map on how to take your company from a shallow practice that helps sort out individual needs to a fully functional business model. When adopted in conjunction with Kanban automation software, the KMM enables organizations to evolve and improve processes, business outcomes and customer expectations, and drive business resiliency and robustness.

  • Harness Acquires Drone CI Project

    Harness Acquires Drone CI Project

    Harness announced it has acquired Drone.io, creator of the open source Drone continuous integration (CI) project.

    Company CEO Jyoti Bansal said Harness, which provides a continuous delivery (CD) platform delivered as a service, will offer Drone to organizations that want a CI platform alongside a CD service from a single vendor. However, Harness will also continue to facilitate the integration of its namesake CD platform with other CI platforms.

    Drone will continue to be freely available as open source software and will be re-christened Harness CI Community Edition. Drone Enterprise will be sold as Harness CI Essentials Edition. Later this year, Harness plans to introduce Harness CI Enterprise Edition, which will extend the core platform.

    The two companies claim there are currently more than 50,000 active Drone community users for a project that is supported by 250 contributors. Organizations that have adopted Drone include eBay, CapitalOne, Cisco Systems and VMware. Instead of requiring scripts, continuous integration pipelines created in Drone can be declared and managed as code in Git. That approach creates a standard syntax for pipelines that are easier to create, use, maintain and troubleshoot. The two companies claim that reduces the time and cost of continuous integration by a factor of five to 10 over rival platforms.

    Analyst firms are projecting the DevOps software market will generate $15 billion in revenue by 2023, signaling an opportunity to provide a more modern CI platform that is easier for organizations to employ, Bansal said. Jenkins, the most widely used CI/CD platform today, traces its lineage back to 2004.

    While the overall market continues to grow, however, there’s been a wave of consolidation among vendors attempting to construct end-to-end DevOps platforms. Many enterprise IT organizations tend to prefer to rely on as few vendors as possible to reduce integration costs, which is an issue Harness in part is trying to address by acquiring Drone.io.

    Harness is a member of both the Continuous Delivery Foundation (CDF) and the Cloud Native Computing Foundation (CNCF). Drone is already available on a wide variety of platforms, including Kubernetes, and it’s not clear if either arm of the Linux Foundation will play a major role in advancing the development of Drone. The CNCF has thus far accepted Argo, an open source CD platform for Kubernetes, as an incubation-level project.

    In the meantime, competition among providers of CI/CD platforms is intensifying. Jenkins, originally developed by CloudBees, is now being advanced under the auspices of the CDF along with Jenkins X, a CI/CD for Kubernetes environments, and Spinnaker, a CD platform originally developed by Netflix. GitLab, Microsoft and its GitHub subsidiary, JFrog and CircleCI all have established major rival CI/CD ecosystems of their own.

    Ultimately, it will be up to each IT organization to decide which CI/CD platform makes the most sense for them. It’s even possible many departments within the same organization will make use of multiple CI/CD platforms. Over time, however, most enterprise IT organizations are expected to adopt a CI/CD standard to better facilitate collaboration across multiple DevOps teams.

  • Atlassian Adds Asset Management to ITSM Portfolio

    Atlassian Adds Asset Management to ITSM Portfolio

    Atlassian this week announced it has acquired Mindville, a provider of IT asset management software that the company plans to integrate with its Jira ServiceDesk platform.

    Edwin Wong, head of product for IT at Atlassian, said Mindville will extend the reach of its IT service management (ITSM) portfolio, which includes Opsgenie for incident management, Jira for project management and the recently acquired Halp software for conversational ticketing.

    Mindville, which already makes its software available on the Atlassian marketplace, has more than 1,000 customers including NASA, Spotify and Samsung. The acquisition of Mindville presents an opportunity for those IT teams to manage IT assets within the Jira ServiceDesk platform, which is widely employed as a help desk to manage interactions with end users, said Wong.

    Atlassian has been steadily bolstering its ITSM portfolio at a time when competition across the sector is fierce. In the wake of the COVID-19 pandemic, many IT organizations are re-evaluating their IT help desk platforms now that it has become apparent many employees will be working from home much more regularly.

    At the same time, IT organizations are looking to reduce the total cost of IT, which becomes easier to achieve if they acquire all their ITSM tools from a single vendor. Going forward, Wong said IT teams should expect Atlassian to continue to tighten integration across both its ITSM and DevOps tools portfolio. The goal is not so much to converge every offering into a single platform as much as it is to seamlessly share data between all the tools that make up that portfolio, he said.

    Atlassian this week disclosed it generated $1.6 billion in revenue for the fiscal year, a 33% increase over the prior year. Total revenue was $430.5 million for the fourth quarter of fiscal 2020, up 29% from $334.6 million for the fourth quarter of fiscal 2019. Atlassian ended the fourth quarter of fiscal 2020 with a total of 174,097 customers based on an active subscription or maintenance agreements. The company said it added 3,046 net new customers during the quarter. However, it recorded a net loss of $385.2 million for the fourth quarter of fiscal 2020, which included a non-cash charge of $382.7 million.

    Atlassian tools can be deployed on-premises or in the cloud and the company has been offering discounts to IT organizations as an incentive to entice customers to shift to the cloud. In the wake of the economic downturn, it’s not clear to what degree organizations will prioritize spending on ITSM tools. However, with more employees and IT administrators now working from home, the need for cloud-based tools to manage a highly distributed IT environment has never been more apparent. One of the things that will differentiate Atlassian is the teams-centric approach the company takes toward ITSM and DevOps, said Wong.

    In the meantime, as the Atlassian ITSM and DevOps portfolio expand, IT teams should expect the divide these two distinct approaches to managing IT to continue to narrow.

  • GitLab Extends Scope, Reach of CI/CD Platform

    GitLab Extends Scope, Reach of CI/CD Platform

    The latest update to the GitLab continuous integration/continuous delivery (CI/CD) platform adds a bevy of additional capabilities spanning multiple capabilities, from being able to manage application development and deployment projects in smaller chunks to allowing remote teams to work more efficiently.

    Brendan O’Leary, senior developer evangelist for GitLab, said a Minimal Viable Change (MVC) capability in version 13.2 enables DevOps teams to break down work into smaller, more manageable chunks that are less disruptive. At the same time, GitLab is further reducing disruption by enabling deeper integration with Jira project management software from Atlassian. DevOps teams can provide bulk updates to projects using Jira in addition to creating confidential “epics” that only a limited number of users can access, said O’Leary.

    GitLab Geo has also been updated to improve replication performance to ensure local content is fresh. That capability has become especially crucial for DevOps teams that now routinely have large numbers of members who are working from home to help combat the spread of COVID-19. Many DevOps teams were already often working remotely prior to the pandemic; now large organizations are moving to extend those efforts at scale because it’s not clear when, if ever, DevOps teams might be heading back into an office, noted O’Leary.

    Other new capabilities include CI test results within a Release Evidence module for tacking compliance data; a global search tool for GitLab.com; tools for tracking designs stored in GitLab; and the ability to run custom load tests as part of a CI/CD pipeline more easily.

    DevOps teams can now associate Feature Flags with related issues; invoke container host monitoring and blocking; track changes to wiki pages; drive feedback into web-based integrated development environments (IDEs) in real-time; enable PHP developers to access a Composer Repository to discover dependencies; and employ a Code Quality Merge Request widget.

    Finally, DevOps teams can run the GitLab Runner tool to launch jobs on instances of z/OS running on IBM mainframes. O’Leary said that capability is especially critical as more organizations that have mainframes embrace best DevOps practices to drive digital transformation initiatives.

    In general, digital business transformation initiatives are fueling adoption for DevOps as organizations look to accelerate these initiatives to reduce overall costs and potentially increase revenue. As part of those efforts, O’Leary said organizations are looking for a highly integrated DevOps platform that minimizes the amount of time and effort DevOps teams need to spend integrating components and managing the platform. That urgency is also driving more organizations to embrace the software-as-a-service (SaaS) edition of GitLab, he added.

    In the meantime, competition among CI/CD platform providers continues to intensify in the wake of an ongoing wave of consolidation. The paradox is that consolidation is not being driven by declining demand; rather, many IT organizations are looking to streamline DevOps processes by standardizing on a single platform. As such, the race to add as many capabilities to a CI/CD platform as possible has never been more heated.

  • Solving the DevOps Dilemma in the COVID Era 

    Solving the DevOps Dilemma in the COVID Era 

    The coronavirus pandemic is forcing businesses to double down on DevOps transformation initiatives across the enterprise, pushing companies to be more agile and implement software changes throughout their organization at a much faster rate. However, too many IT departments rely on older, complex processes to approve software changes coming from DevOps teams and simply cannot keep pace with this accelerated rate. This is because many parts of the delivery process remain heavily manual, time-consuming and siloed. In other words, rather than realizing enterprise-wide transformations, the value from DevOps initiatives is remaining localized and doesn’t come close to delivering on the promise DevOps held in the first place.

    But because of the profound and sudden changes to the way we work, the industry is reaching an inflection point. Increased demand and competitiveness for modern digital experiences and ways of working are forcing businesses (even those within highly regulated industries) to rethink how they build software and get it approved faster. The need is clear among developers to reduce time-to-approval for new features, yet organizations must remain steadfast in protecting the business against rushed features that may not contain the proper safeguards and could negatively impact business operations.

    To help strike a balance during this critical time, a new trend to expedite software development and deployment is emerging: a platform-based approach to DevOps.

    Driving Visibility With Platforms

    The potential for platforms to streamline aspects of DevOps is profound. Platforms are able to model data and workflows to connect developers and IT continuously all along the development and delivery process. For example, the platform can leverage information from the flow to automate the manual and time-consuming change approval process, enabling them to release features rapidly and safely.

    But the benefits of platforms transcend beyond workflows. The vast number of tools used by developers and IT makes it difficult for leaders to get a holistic view of how each team is performing. This lack of visibility slows the behavioral and cultural change needed to succeed with DevOps. However, with the system of record and engagement that the right platforms provide, stakeholders on both sides of a project can easily view and audit the release process, which means shorter development cycles, increased deployment frequency and more dependable, high-quality releases.

    Companies, and even teams within the same company, are at many different stages of DevOps maturity. Some are fully adopting distributed teams based around products and simple development pipelines that make rapid, incremental changes, potentially multiple times per day. However, most organizations still have more complex releases that are still on a longer cadence such as weekly or monthly. Those releases may involve multiple teams and a wide range of development tools so again, the platform approach provides visibility and the ability to automate across the entire release.

     DevOps at Scale

    While many businesses are leveraging DevOps in various capacities, they have yet to be able to scale adoption across their entire organizations. This is the Achilles Heel for DevOps as a whole—after all, the goal with any transformative initiative is to scale, and traditionally DevOps has been difficult to scale past initial early successes.

    The challenge in scaling DevOps is that while there are many tools at developers’ fingertips, the actual processes around audit, compliance, security and change management are still often performed manually, and many of the tools are disconnected, meaning fragmented data and, yet again, limited visibility across numerous teams within an organization. At a time when controls should be becoming more decentralized, with more operational parameters ‘moving left’ to the control of development teams, we are instead seeing delays during deployment, difficulty driving best practices and DevOps adoption across the enterprise, and a lack of trust across teams.

    However, with a platform approach, the ability to scale is built into the technology since software approvals can be automated, enabling IT teams to allow more decision-making in development with appropriate guardrails. The IT teams can ensure the release of features rapidly and safely—and more importantly—focus on strategic, business-critical work.

    Resolving Data Configuration Challenges With Platforms

    In addition to unlocking visibility and scale with DevOps platforms, there’s a growing practice of leveraging platforms to improve configuration data. As companies shift to working in the COVID-19 era, they’re using more applications that require frequent updates. To ensure the applications don’t break in production, developers are automating application testing and deployment with platforms, allowing this process to occur earlier in the software delivery life cycle.

    However, ensuring configuration data accuracy during this process can be challenging. By using a platform for developers to add and consolidate configuration data, users can better control the application environment, prevent issues in production and quickly correct post-deployment problems. All this is possible by integrating machine learning into the platforms to prevent incorrect configuration data settings from reaching production environments. The machine learning identifies potential misconfigurations earlier, before apps are moved into production, ultimately helping users avoid app and infrastructure deployment inconsistencies.

    With platforms, developers can both improve the quality of configuration data and identify incorrect configurations using machine learning ultimately to prevent software changes from causing outages and incidents during a highly critical time.

    The Bottom Line

    The coronavirus pandemic has magnified the importance of agility and quickly adapting technology to meet changing customer and employee needs. As a result, enterprises are trying to figure out how to navigate and embrace new technologies that help ensure business resiliency. When done right, DevOps should help accelerate and scale this innovation, while still maintaining compliance and security. Adopting a platform-based approach to DevOps helps organizations reduce time-to-approval of new features so they can effectively drive digital transformation across the business—the North Star of all IT initiatives in this new work environment.

  • Puppet Launches Relay to Simplify Automating DevOps Workflows

    Puppet Launches Relay to Simplify Automating DevOps Workflows

    Puppet today made available a public beta of Relay, an event-driven platform through which DevOps teams can automatically invoke pre-configured workflows.

    Company CTO Deepak Giridharagopal said Relay listens for DevOps events that can then trigger an automated workflow such as automatically deleting underutilized cloud resources, enforcing cybersecurity controls or remediating known issues.

    Relay connects to dozens of DevOps tools, cloud services and application programming interfaces (APIs) to automate workflows across a wide range of platforms, including PagerDuty, GitHub, Datadog, Jira, Terraform, Slack and others.

    Giridharagopal said Relay will also enable IT organizations to reuse workflows versus continually cobbling together one-off workflows for processes that address routine use cases that can be tackled using existing content.

    At the root of that issue is tool sprawl within DevOps environments. Each DevOps team tends to create their own workflows using their preferred tools, even though they may be replicating a workflow process that has already been addressed using other tools. Relay provides a means to reuse workflow across disparate DevOps tools, which Giridharagopal said should significantly increase overall DevOps productivity.

    The Relay platform is also designed to be extensible in that it also allows DevOps teams to create custom workflows that can then be reused by other members of DevOps teams, he added.

    Giridharagopal said with the rise of microservices it’s apparent workflow automation within DevOps environments is about to become a more pressing issue. As the number of individual services that need to be managed increases, the need to automate workflows across more complex IT environments becomes more critical. DevOps teams can’t effectively manage modern cloud-native applications relying on manual workflow processes, he said.

    Relay is part of a broader shift toward event-driven architectures, which are gaining increased traction within IT environments. While event-driven architectures have been around as a concept for decades, the emergence of platforms based on, for example, serverless computing frameworks are changing how IT resources are invoked. Via any number of APIs, it’s feasible to automate a wide range of IT functions using these types of platforms.

    Of course, the biggest challenge for many organizations has been building automated workflows that work consistently across multiple platforms. The level of process expertise required to build those workflows is not inconsequential. Puppet, via Relay, is providing pre-configured workflows to address some of the more common use cases in a DevOps environment. DevOps teams will still need to build their own custom workflows to address more complex use cases. However, platforms such as Relay promise to sharply reduce the time spent creating scripts and associated workflows to address routine tasks.

    In the meantime, interest in all forms of IT automation is on the rise in the wake of the economic downturn brought on by the COVID-19 pandemic. IT organizations are moving quickly to reduce the total cost of IT by automating as many processes as possible. In many cases, it’s not clear when some IT organizations might be able to add additional headcount anytime soon. Automation, as such, is now as much about survival as it is simply trying to increase productivity.

  • Pinpoint Dives Deeper into Software Delivery Analytics

    Pinpoint Dives Deeper into Software Delivery Analytics

    Pinpoint has extended its platform for managing software delivery to include the ability to analyze historical events to facility team reviews as well as more accurately predict where bottlenecks are likely to emerge based on the past performance of the DevOps team.

    Company CEO Jeff Haynie said the company’s namesake software is employed today mainly to identify existing software development bottlenecks. Pinpoint is now making greater use of machine learning algorithms and advanced analytics to surface additional insights and recommendations, he said.

    Designed to collect data from multiple tools and platforms spanning a DevOps process, Pinpoint automates most of the tedious tasks associated with collecting the metrics required to manage a distributed development team, Haynie said. With more developers working from home in the wake of the COVID-19 pandemic, that ability to collect metrics automatically also plays a key role in allowing application development managers to set more meaningful agendas for meetings that now occur via videoconference rather than in a physical conference room.

    In effect, the application development process can no longer be managed by simply walking around the office to find out what everyone is working on, he noted.

    The analytics should also serve to make events, otherwise known as ceremonies, more meaningful because they can include metrics detailing what was actually required to achieve a specific goal, he added.

    Ultimately, the goal for any DevOps team should not be to simply write more code faster. IT leaders need to make sure the right code is being delivered at the right time to ensure application development projects stay on track.

    Providers of various DevOps platforms have been investing in tools to manage the software delivery process. However, each of those offerings is optimized for a specific platform. The Pinpoint dashboard can be integrated with any platform, including Azure Team Foundation Server (TFS), GitLab, GitHub and Bitbucket. Assignments made in Pinpoint can also then be automatically reflected in these platforms as well as project management applications such as Jira, said Haynie.

    One of the biggest issues with software engineering is that, from a business perspective, it’s been a “black box” that has made it difficult to plan. The more dependent a business is on software, the more problematic that issue becomes. Many issues could be avoided if only there was more visibility into how software development resources are being applied when and where. In fact, as more organizations prioritize digital business transformation in the wake of the COVID-19 pandemic, the more critical it becomes to maximize use of limited software development resources.

    Of course, organizations have been trying to manage software development projects using spreadsheets and project management applications for decades. The tools are not likely to be replaced anytime soon simply because of the level of process inertia attached to them within most organizations. However, given the current state of application development, it should be apparent those tools are not enough to get the job done on time.

  • Participate in the Checkmarx 2020 Survey

    Participate in the Checkmarx 2020 Survey

    Checkmarx, the global leader in software security solutions for modern enterprise software development, and staging-devopsy.kinsta.cloud are conducting a survey about the implementation of DevOps and related automation and security tools.

    The purpose of the survey is to help organizations evaluate their DevOps maturity, find out what are the most used DevOps tools and the most common challenges organizations are facing with their current DevSecOps model.

    The survey consists of 16 short multiple-choice questions. The results will depend on several factors including:

    • The organization’s progress on their DevOps adoption journey.
    • The role of the respondents in their organization and their responsibilities for DevOps transformation.
    • Automation and security tooling capabilities respondents are using for DevOps and cloud-native applications.
    • The respondents’ ability to overcome challenges and obstacles standing in the way to successfully implementing DevOps.

    We urge everyone in the DevOps space to participate in this survey. The more data we can gather, the more we’ll find out about the adoption of DevOps and AppSec tools. We’re counting on you to make this report even more valuable. Invite your friends and colleagues to contribute to the survey, too — the more the merrier.

    Click on this link to complete the survey.

    We will make an announcement when the report is ready. Stay tuned!

  • Rookout Extends Reach of Debugging Platform to On-Prem

    Rookout Extends Reach of Debugging Platform to On-Prem

    Rookout, a provider of a software-as-a-service (SaaS) platform designed to simplify the debugging of applications, has extended the reach of its tools into on-premises IT environments.

    Company CTO Liran Haimovitch said its new Data On-Prem capability extends the reach of a bytecode manipulation capability developed by Rookout to insert a snapshot capture of a specific line of code to an on-premises IT environment. This eliminates the need for DevOps teams to upload code and associated data to the Rookout platform manually.

    The Data On-Prem capability is made available via a software development kit (SDK) provided by Rookout, he said.

    Legacy approaches to debugging code are essentially broken because the processes employed to fix code are too cumbersome, said Haimovitch. Rookout is designed to collect full-stack data without requiring code to stop running or impact code execution. That approach allows developers to debug live code on the Rookout platform and then reinsert the code into their applications.

    Haimovitch said Rookout is making a case for transforming how application debugging is addressed within a DevOps process. Rather than relying on tools that need to be tightly integrated and maintained within a continuous integration/continuous deployment (CI/CD) pipeline, it will be easier for developers to debug live code on the Rookout platform, said Haimovitch.

    That approach will enable DevOps teams to go well beyond simple observability to embrace true understandability of how applications work down to individual lines of code, he added.

    Debugging applications has always been problematic. In an ideal world, developers would have a much better handle on what bugs need to be fixed earlier rather than later. By making it easier to debug live code, the number of issues that developers could address before an application is deployed in a production environment should increase. It may never be possible to address every issue before an application is deployed; however, the number of critical issues theoretically should decline. Many code issues go unaddressed simply because the effort required to debug that code is too great. Many developers too often put off fixing those issues until the next update usually because they are rushing to meet a delivery deadline.

    At the very least, developers should repeat the same mistakes less often as they work to debug live code.

    Regardless of how the debugging issue is addressed, issues within code in the age of microservices are starting to have a bigger impact. An issue within a line of code in a single microservice can have a cascading impact on all other elements of an application that depend on that microservice.

    Debugging application code is never going to be enjoyable. The challenge is finding a way to make the entire process less painful. There may come a day soon when machine and deep learning algorithms help automate much of the debugging process. In the meantime, DevOps teams might want to re-evaluate existing approaches to debugging code that clearly leave much to be desired.