devopsy.kinsta.cloud

Tag: developer productivity

  • 6 Ways To Empower Developers and Increase Productivity

    6 Ways To Empower Developers and Increase Productivity

    A big goal of DevOps is to increase productivity. Yet many organizations still struggle with the efficiency of their software release processes. In fact, 54% of engineers stated they have too many manual steps within their deployment process, according to an Armory survey. And with the pervasiveness of multi-cloud, developers now face an escalating number of deployment environments, each carrying their own nuances.

    Development teams want to move as quickly as possible without barriers. Yet, there are often hurdles to seamless deployments. For example, the code might be 100% ready to deploy, yet someone still must validate it before it reaches production. Manual bottlenecks like this in the CI/CD process can make developers feel like their code isn’t worthy of deploying and may even amplify feelings of burnout.

    I recently met with Anna Daugherty, senior product marketing manager at Armory, to see what technology leaders can do to remove barriers within their software release cycles and increase productivity. According to Daugherty, many of these strategies boil down to having empathy for developers and their needs. “Developers aren’t machines; they’re people, and people deserve to have a quality of life when they’re doing their jobs.” Below, we’ll highlight tips and tricks to keep in mind to improve release fluidity.

    1. Identify Where Your Manual Checks Are

    The first step to speeding up CI/CD is identifying where manual steps exist within the development workflow. The DevOps life cycle, often visually depicted as an infinity loop, includes many states, such as design, build, test, deploy, assess and monitor. But if each step has one or more manual steps, you accrue a lot of manual debt, said Daugherty.

    Therefore, engineering leads should seek to remove manual checks whenever possible. Of course, this may not be realistic within certain situations, such as financial institutions that require manual approvals at the last mile. However, everything should be smoothed out and automated up to that point, said Daughtery.

    2. Shift From Continuous Delivery to Deployment

    Depending on who you ask, the ‘CD’ in ‘CI/CD’ may stand for continuous delivery or continuous deployment. As part of reducing friction in the software release process, Daughtery encourages teams to begin to embrace the latter whenever possible. If deployment remains inhibited by unnecessary manual steps, it can decrease scalability and interoperability.

    3. Increase Confidence With Testing

    Of course, if we introduce more automation into the CI/CD pipeline, we must ensure the software is rigorously tested for errors and vulnerabilities. Daugherty encourages development to embrace automated, continuous testing approaches at every juncture, whether pre-production, inter-production, or throughout the application lifecycle. There are also advanced deployment strategies to consider, such as canary testing, which rolls out new changes only to a small subset of users or blue-green deployment can deploy to different places at different times.

    These deployment strategies can help build confidence while reducing the risk of disrupting a majority of your user base with untested production updates. “The more you can integrate testing into your process, the more confident your process will become,” said Daughtery.

    4. Chose The Right Toolsets

    So, how do we implement more automation into the DevOps cycle? And what sort of tools should we look for? According to Daugherty, when scouting for DevOps tools, technology leaders should prioritize open solutions that aren’t closed-off environments. Instead, they should offer flexibility and the ability to integrate with the tools you already use every day. “You can have all the tools in the world, but if they don’t fit together, that can drag down the process.”

    5. Consider Open Source Software (OSS)

    On that note, consider open source software (OSS) where possible. OSS like Argo or Spinnaker has the potential to empower developers and bridge gaps in the CI/CD process. Other projects from the Cloud-Native Cloud Native Computing Foundation (CNCF) and Continuous Delivery Foundation (CDF) are mature with proven stable adoptions.

    And although there is some weariness around OSS, particularly around unknown vulnerabilities and project maintenance concerns, “you can still be successful, secure, and scalable with open source,” said Daugherty. Open source also delivers community benefits and helps engineers feel like they are part of a bigger picture. “[OSS] is the opposite of burnout. It brings people together. It’s a community builder.”

    6. Become Developer-First

    Transitioning into a developer-first organization is another way to increase developer satisfaction and efficiency. But to become a developer-first organization, developers will need more say in the processes—this will involve balancing top-down requirements with total developer control. For example, leaders should suggest tools to enhance productivity but accept feedback on an ongoing basis to see what works best.

    To support these efforts, the concept of developer experience (DX) has entered the lexicon in recent years. Building with developer empathy can result in more usable, frictionless software that increases productivity. DX is crucial within the burgeoning area of platform engineering, as the goal is to create reusable, internal self-service platforms for developers to leverage.

    Interestingly, Netflix extolls what it calls full-cycle development, in which a developer oversees the building and operational aspects of a single component throughout its entire life cycle. “It’s an interesting way of addressing burnout because you feel more connected to what you create,” said Daugherty.

    Final Thoughts: DevOps Isn’t Dead

    Above, we’ve highlighted some potential strategies to increase developer productivity. By replacing manual bottlenecks with more automation, you can increase deployment fluidity. Considering how tools are acquired and iterating upon feedback from engineers can also help improve consistency while retaining quality talent.

    Looking to the future, Daughtery hopes that similar roles such as DevOps, site reliability engineering and platform engineering can come together and join forces. Because, at the end of the day, they share many goals. And contrary to some grabby headlines, DevOps is far from becoming obsolete. DevOps is not dead. It’s very much alive and increasingly important.

  • The Advent of Intelligent Software Engineering 

    The Advent of Intelligent Software Engineering 

    Today, to maintain competitiveness, every company needs to behave like a software company and deliver new solutions with high velocity, quality and reliability. New features need to be introduced at a rapid pace, but with high-quality expectations. At the same time, deployment releases and operations are getting complex, debugging and traceability in production are increasingly difficult, security is more prominent, uptime and reliability needs have scaled up dramatically … the list goes on.

    In short, traditional software engineering is changing radically.  Some trends causing this disruption include:

    • Cloud is eating software. And that has not only changed the infrastructure where software is hosted but also how applications are architected, developed, packaged and deployed. Cloud is driving the adoption of cloud-native technologies; serverless components and containerization have changed how we build applications. The hard line between development and infrastructure team is getting fuzzy. 
    • Cybersecurity is now a boardroom concern. Rising cyberattacks and malware threats have left everyone vulnerable. Traditionally, software was released every few months, leaving enough time for security testing by specialists. Today, with the advent of very rapid release cycles, security checks need to start early in the development process.
    • AI/ML is the new electricity but is causing shocks. AI/ML-powered use cases are finding their way across platforms, and across industries. Traditional software engineers are not familiar with AI/ML and ML developers are not familiar with engineering disciplines and best practices, leaving a big divide in engineering maturity.
    • When one company raises the bar, others are expected to follow. Consumer expectations are constantly changing. They expect the same experience that they get from Amazon, Uber and Google from every application. It is expected that you provide a seamless, frictionless experience that your platform is available anytime, on any device and that it is fast and secure. 
    • APIs are fueling innovation: Innovation at speed and scale is not easy, but APIs can enable exactly that by tapping into the collective power of the crowd. Today, any developer can use platform-provided APIs to build a new, innovative solution. An API-first mindset is emerging, and the app store model (e.g., Apple App Store, Salesforce AppExchange, AWS Marketplace) has changed how we think of innovation and creating new platform extensions. 
    • Low-code/no-code platforms are quickly evolving, making it easy to develop small, situational applications without writing any code. Citizen developers are emerging. 
    • Modern architecture paradigms drive new ways of working. Modern platform architecture has evolved significantly in recent years from monolithic applications to SOA to microservices- and API-based distributed platforms. Event-driven architectures have gained prominence. Streaming architecture has become increasingly popular to support massive scalability. This has a significant impact on how engineering teams are organized and how they build, test, deploy and manage new platforms. 
    • Legacy platforms are slowing down growth. Legacy applications built 20+ years ago needs to be modernized for today’s context. Modernization is a massive exercise depending on the age, technology and the size of the application. But modernization is easier said than done. The legacy and the new worlds need to coexist for a while and need a bridge strategy from both a technology and cultural perspective.

    To meet these changing demands, engineering needs to become a lot more intelligent.  

    The Advent of Intelligent Engineering

    We can bring intelligence to engineering by using more data to manage projects, leverage AI/ML analytics to bring improve engineering productivity and predictability, leverage more automation and apply the right process to the right problem. 

    Data-driven Decision-Making in Engineering 

    Engineering teams use numerous tools in the development environment for code repository, bug tracking, code scanning, build, test, deploy, etc. Popular tools include Azure DevOps, GitHub, Atlassian and Jenkins, among others. These tools generate lot of granular data. All these data silos can be aggregated and used to track interesting metrics around:

    • Developer productivity: How much time is spent on writing how much code versus other activity; story points delivered versus committed
    • Software quality: Number of bugs generated; rate at which bugs are being fixed; number of bugs that slip into production 

    Additionally, on top of this data, one can build an intelligence layer using machine learning to draw hidden insights, highlight co-relations and conduct better root cause analysis. These insights can bring greater predictability to engineering outcomes. For example, whether or not developers can meet a release schedule, the level of quality, etc.

    Data provides evidence of how your teams are performing. It helps in removing potential roadblocks and enables better communication with all stakeholders. It can be used to better manage project performance and be leveraged for objective decision-making. Despite the availability of this data, engineering leaders are still operating in the dark. Decisions are made based on intuition and gut feel rather than on hard data. It’s time to become more intelligent by using data in project performance tracking and decision-making. 

    Elevate Productivity and Predictability of Engineering Services With AI

    AI/ML is disrupting every industry and is now finding its way into software engineering. AI/ML-enabled developer tools are emerging that can be leveraged across the software engineering life cycle. These tools can not only save time for repetitive activities but also improve software quality in large and complex tasks. 

    AI/ML-enabled tools can enhance a developer’s daily life from coding to testing. Today, AI-powered tools can scan and analyze code to provide intelligent code completion suggestions, flag any deviation from coding best practices (naming convention compliance, variable misuse, etc.), perform peer review, convert code from one language to another, find security vulnerabilities, etc. Dynamic application security testing (DAST) solutions use AI to discover potential attack vectors in milliseconds which would otherwise take a few days. AI/ML can help auto-generate HTML code from hand-drawn UI sketches. AI/ML also can help developers automatically generate unit tests from existing code and provide suggestions about improving tests.  

    In fact, testing is the biggest category that can benefit from AI/ML-based intelligence, specifically in large complex applications. QA teams who rely on manual testing are not able to keep pace with the rate at which code changes and releases are done today. AI/ML-enabled tools can help testing teams in a number of specific ways. 

    • Change impact analysis: AI/ML can help with coverage analysis and identify which tests need to run based on what has changed in the application.
    • Test creation: AI/ML can help test teams create test cases from plain English descriptions and can also learn how to improve tests over time; AI/M also can automatically heal broken tests. AI-powered tools can automatically convert manual UI tests to API tests.
    • Visual testing: AI-powered image comparison technology can enable visual testing to analyze the UI screen differences detected across tests. 
    • Test analysis: AI can analyze test cases and defect metrics to increase test coverage while reducing the number of tests.

    It’s time to become more intelligent by using AI-powered tools to augment engineering teams, improve their productivity and bring predictability. 

    Intelligent Automation: Beyond Development Processes

    Today, there are a lot of automation options in the software development life cycle. DevOps enables automation of build, test and deployment of new versions of your software. You can also automate other activities such as test automation, code scanning, performance test, etc. DevSecOps enables automation of security processes (e.g., code scanning for vulnerabilities) into the engineering life cycle. AI/ML-powered tools can further drive automation improvements (e.g., improve flow in your CI/CD pipelines.) Overall, automation enables higher team productivity and results in the rapid or on-demand release cycles required for business agility.  

    Automation is not just limited to development activities, it also applies to other parts of the engineering life cycle, for example:

    • Infrastructure-as-code (IaC) tools can automatically provision and configure cloud infrastructure environments (storage, network, etc.).
    • Monitoring tools can automate monitoring for availability, production load metrics and security problems and generate alerts. 
    • Log management: The number of logs generated in today’s ecosystem is vast and it is impractical to collect them manually. Log management tools can automatically aggregate and analyze information from logs.

    Leveraging automation aggressively and using it throughout the engineering life cycle can make software engineering much more intelligent. You should be automating repetitive tasks and low-value processes and use the saved time for higher-value activities.

    Making Agile Smarter

    There are several popular software engineering methodologies available such as Agile, Scaled Agile, the Spotify model and more. Regardless of the methodology or process you use, intelligent application of the right methods and tools to the right problems can make them more effective, efficient and intelligent. For example, traditional Agile processes were originally designed in the manufacturing space and were then adapted to develop mature software. But in today’s fast-changing market, development teams need to rapidly and continuously try new ideas either to demonstrate new business features or for technical validation of emerging technology. This is true not only in the early stages of new product development but also on existing platforms where you need to keep pace with changing market dynamics. Be ready to experiment.

    We need to get smarter about selecting the right process and tailoring it to your needs rather than let the process dictate your outcome.

    If Software is Eating the World, Complexity is Eating Software

    While product engineering has been around for a long time, modern software engineering is a lot more complex than just writing code and following Agile processes. Intelligent engineering practices can get solutions to market faster with better quality and reliability and gain more time for innovation to keep up with today’s speed of business.

  • Essential Ingredients For a Remote DevOps Team

    Essential Ingredients For a Remote DevOps Team

    Enterprise business processes are run on evolving applications, and the DevOps team needs to be as efficient as the applications they create. Unfortunately, the COVID-19 pandemic has had a profound impact on DevOps productivity—and that impact hasn’t always been positive.

    Tracking the performance of the DevOps team has become more challenging in a remote and hybrid world. Like everyone else, developers have become remote workers throughout the pandemic which means adapting to a new way of working. There has been a lot of research done on the impact of work-from-home on productivity. Of course, measuring any developer’s productivity was already a complex task. It’s not as though you can use a simple metric like the number of lines of code produced per day; it’s a lot more complicated than that.

    Working from home has made it even more challenging for developers to stay productive. There are dozens of distractions when you work from home, and research shows that it can take even the most skilled developer 15 to 20 minutes to resume work once they have been interrupted. There’s also more stress associated with balancing work and home life when working remotely. According to Catalyst, 92% of workers say they are feeling burnout from the stress of remote work.

    Software Development Thrives on Remote Work

    In many ways, the trend toward remote work has been a windfall for developers. The nature of coding has always lent itself to a hybrid or remote work environment, but unfounded concerns about securing intellectual property have always been an impediment.

    A recent Gartner survey revealed that employees are three times more likely to become high performers when given flexibility as to where, how, and when they work. Remote work also enhances flexibility and eliminates wasted time commuting. And work-from-home reduces childcare responsibilities. Catalyst found that 32% of women with child-care concerns are less likely to leave their jobs if they have work-from-home as an option.

    Remote work also eliminates geographic barriers, which is a well-understood benefit in the software industry. Being able to hire programmers working from home anywhere in the world increases the size of the talent pool and makes it easier to find developers with the right skillset.

    Of course, there are challenges for DevOps teams that embrace a remote work model. Communication is probably the biggest challenge. Zoom meetings may not be as effective as in-person meetings since it’s harder to read facial expressions and pick up non-verbal cues. It’s up to the team leader or senior manager to promote effective communications. It’s also important to have the right tools, have the right communications channels and maintain respectful interactions. Even with a remote work environment, the team dynamic can be adversely affected by the misuse of responsibility, behavioral issues and disrespectful behavior.

    Building a Remote DevOps Team

    Supporting collaboration in a hybrid work environment requires new processes, new guidelines and new tools. The best place to start is by choosing the right collaboration platforms and procedures. For example, email is a poor channel for immediate requests, but you don’t want to be answering continuous phone calls. Establish protocols for using email, chat, teleconferences and meetings. Adopting cloud communications tools also gives you more agility and scalability. 

    When choosing the right collaboration tools consider security. Working off-site gives you less control over enterprise access. Remote workers access enterprise systems using different devices and public and private networks. To reduce vulnerability to cyberattacks provide safe and secure network access with multiple security layers. Adopt virtual private networking (VPNs), remote desktop protocol (RDP) clients, and malware protection. Workers tend to be less security conscious when working remotely so take what steps you can to reduce risk.

    In addition to having the right tools, you must have the right approach. To continuously improve efficiency you need transparency, inspection and adaptation, just as you do with DevOps. Start by establishing and documenting a clear set of expectations for the remote team. Also, create a leadership hierarchy. Even though they are working from home, everyone needs a work structure. It’s up to the team leaders to create a stable work environment. Lack of clarity removes that sense of structure and safety and can undermine the team.

    Maintaining transparency is the best approach for any remote work culture. Establishing a workplace fueled by honesty and openness and where every voice is heard ensures everyone is working to achieve a common goal and keeps morale high.

    Maintaining a successful remote work environment depends on respecting the four Cs: Communication, collaboration, connectivity and culture. The four Cs are interdependent and work together to create an effective digital work environment, providing an employee experience across locations, devices, channels and situations.

    Creating a Productive Environment

    Once you have laid the foundation for remote collaboration, the next step is to monitor productivity. There are a few ways to look at DevOps team productivity. You can look at the final output of the overall effort, assessing the application that is the end product. You also can measure overall team productivity. 

    To monitor key metrics to assess team productivity, project managers must be prepared to drill down to evaluate hot spots:

    • Measure output for specific developers and see how it stacks up against the productivity of other team members. 
    • Maintain leaderboards highlighting top contributors. Using gamification creates healthy competition and can inspire greater productivity when top performance is recognized.
    • Create a conducive environment by providing the right set of tools and motivating engineers to be at their best.
    • Monitor distractions. Coding is an intensive activity and disruptions harm productivity.

    Don’t measure productivity based on coding. Developer contributions also include designing new features, functional discussions, code review, documentation, testing and bug fixes, meeting with customers and other tasks.

    Improving DevOps productivity is also a product of automation. In addition to streamlining real-time collaboration with tools such as instant messaging and Microsoft Teams, shortening development time with automated testing tools and AI-powered test frameworks eliminates manual processes and frees time for more productive tasks.

    If you are looking for a silver lining from the pandemic, consider the evolution of the remote work environment. Supporting remote DevOps developers is nothing new, but forcing employees to work from home has made the hybrid work environment more efficient. DevOps teams continue to invent better ways of working that promote flexible work hours, higher productivity and a better work-life balance.

  • Boosting DevOps Productivity Requires Visibility, Automation

    Boosting DevOps Productivity Requires Visibility, Automation

    Engineering teams continue to struggle with roadblocks and bottlenecks during the development process, according to Software’s recent 2021 Code Time Report.

    The study, which is based on feedback from more than 250,000 developers using the Code Time plugin, found the median code time per developer is 52 minutes per day, or four hours and 21 minutes of code time per week. 

    The data also revealed that only about 10% of developers spend more than two hours per day coding, including on weekends, while about 40% of developers spend more than one hour per day coding.

    The study also indicated developers are battling distractions that range from too many meetings and too many interruptions to too much wait time on processes and systems. 

    Distractions, Disruptions and Meetings Dog DevOps

    The conclusion was most companies ineffectively deploy their development and DevOps teams, bogging down engineers with distractions, disruptions and meetings as well as system inefficiencies, such as slow reviews, slow builds and bad tools.

    Software’s CTO Mason McLead said based on the company’s estimates, developers spend an additional 41 minutes per day on other types of work in their editors, such as reading code, reviewing pull requests and browsing documentation.

    “The key to ensuring the highest levels of productivity from DevOps teams is visibility,” he explained. “We’re all biased toward focusing on what’s readily apparent, but the biggest bottlenecks are often hard to find and difficult to measure.”

    McLead said by improving visibility across the entire development life cycle in a way that measures system-level metrics and not individual performance, DevOps teams can focus on the biggest constraint and have a more meaningful impact on their team’s productivity.

    He said one example of a productivity metric with hidden barriers is lead time.

    “I’ve spoken with many managers who disproportionately focus on how long it takes to review pull requests as a key lever to minimize lead time,” he said. “However, there are many stages in releasing a new feature that might actually be the key constraint—for instance, how long it takes to test and validate changes in a staging environment, or how long it takes to release merged pull requests to production.”

    While these stages of lead time are all measurable, McLead explained most DevOps teams don’t have a data pipeline or BI tool set up to measure them.

    He added that once an organization can diagnose the key constraint, it’s a lot easier to come up with an effective solution to minimize that constraint.

    For example: If pull requests are taking a long time to create, are tickets being properly scoped? Can you see a correlation between the size of the pull request and the time it takes to be approved and merged?

    McLean pointed out that if pull requests are taking a long time to be reviewed, it is critical to ensure proper expectations are being set.

    He added it’s important to determine if there is a system in place to remind reviewers and enough time set aside in the day to perform the review.

    “Taking steps to further automate deployment processes are another potential fix if it currently takes a long time to deploy a change to production,” McLead said. “It really all comes down to being able to measure the top constraint so that you know where to spend your time.”

    Remote Work and Visibility

    Remote work is also expanding the role of traditional DevOps teams: The trend toward more flexible working styles will demand more investments in DevOps such as secure provisioning of remote infrastructure, better access management and improved developer onboarding to better enable productivity for development teams.

    “Visibility into how your DevOps investments are making an impact will play a big role in the decision on whether to stay remote or return to the office,” McLead said. 

    He added one way to attract and retain a highly productive DevOps team is to show that your DevOps investments are paying off.

    “I recently talked to an engineering manager whose team wasn’t getting features out fast enough,” he said. “It took a month on average to complete a ticket, which had a significant impact on their ability to move major roadmap items forward.”

    He explained that by implementing measures to improve throughput (e.g. investing in CI/CD, reducing build times and improving test coverage), they were able to decrease lead time from one month to four days.

    By setting up a data pipeline and BI tool and increasing visibility, the engineering manager was not only able to report on metrics to his executive team and board with confidence, but also boost morale on his team.

    From McLead’s perspective, retaining talented and trained DevOps engineers is critical because many DevOps projects require a longer timeframe in which to implement and measure their success. 

    “Highly effective DevOps teams measure not only how their investments are improving efficiency in the short-term, but also how changes in throughput and productivity are trending over months and years,” he said. “If your team is experiencing high turnover, it’s even more difficult to consistently deliver results over these longer time frames.”

  • GitHub Expands Developer Productivity Tools Portfolio

    GitHub Expands Developer Productivity Tools Portfolio

    During the online GitHub Universe 2021 conference, GitHub today unveiled a bevy of updates intended to boost developer productivity by making it easier for developers to write code faster and collaborate more easily.

    The GitHub Copilot tool that GitHub developed in collaboration with OpenAI, a research and development lab, to help developers write better code faster is being extended via a technical preview to add support for Java and the integrated development environment (IDE) JetBrains.

    In addition, the Codespaces tools that GitHib makes available to pre-configure development environments is being extended to include support for devcontainer feature composition, the GitHub command line interface (CLI) and REST application programming interfaces (APIs) along with additional access controls.

    GitHub Actions has also been updated to add support for deployments using the OpenID Connect standard in addition to providing access to deployment environments to simplify approvals, improvements to reusable workflows and auto-scaling functionality for self-hosted runners.

    There is also now a Command palette tool in beta to help developers navigate GitHub along with a public beta of a GitHub Issues tool that makes it simpler for developers to filter, sort and group issues and pull requests. Additional features that have been added since GitHub Issues was first previewed include iteration support, reporting and data visualization tools and the ability to employ it across public projects.

    Finally, GitHub is adding, in beta, support for Ruby as a programming language that CodeQL analysis engine can now scan for vulnerabilities along with the ability to customize permissions for accessing GitHub Enterprise Cloud.

    Ryan Salva, vice president of product management for GitHub, said collectively GitHub is committed to making developers more productive by, for example, autocompleting code as developers write. Support for additional programming languages will also be forthcoming in the months ahead. The goal is not to leverage AI to replace developers but, rather, eliminate the drudgery that gets in the way of developers becoming more creative, noted Salva.

    There won’t come a day any time soon when developers won’t have to type to write code, but it is possible to leverage AI to provide a type-ahead capability that reduces coding errors, added Salva.

    The goal should be to enable developers to create more application experiences at a time when more organizations than ever are consuming applications that drive a wide range of digital business process transformation initiatives, said Salva.

    As part of that effort, Salva noted it’s also critical to reduce the amount of friction developers encounter writing code starting with setting up the development environment itself.

    It’s not clear yet what impact all the focus on developer productivity and collaboration will have on the rate at which applications are being built and deployed. However, as developers become more productive, the number of application development projects that can be launched simultaneously should increase. In fact, there may come a day when applications are being built faster than organizations can deploy them without adopting continuous delivery best practices that rely on higher levels of automation to install software.

    Regardless of that application delivery challenge, however, it’s a problem most organizations right now would consider themselves fortunate to have.

  • Anaxi Adds Reporting Capabilities to ALM Tool

    Anaxi Adds Reporting Capabilities to ALM Tool

    Anaxi today announced it has added reporting capabilities to its namesake application lifecycle management (ALM) tool that make it possible to update stakeholders about the status of software development projects residing in repositories such as GitHub and Bitbucket Cloud as well as project management applications such as Jira.

    Company CEO Marc Verstaen said reporting capabilities will make it easier to employ Anaxi to, for example, keep business leaders apprised of updates to software development initiatives by enabling IT leaders to generate a report similar to how business leaders today employ a business intelligence (BI) application to share sales forecasts.

    The Anaxi tool is designed to provide IT leaders with a single tool for tracking progress being made across multiple DevOps platforms. Verstaen said as more organizations begin to realize they are really software companies, interest in software delivery management tools is on the rise. The reporting challenge IT leaders face is the information they need to create a holistic report lies in multiple repositories because of the inherently fragmented nature of the DevOps tool chain, he said.

    To make it easier to adopt Anaxi, the ALM tool Data employs the same credentials organizations have created to access GitHub, Bitbucket and Jira. The Anaxi app connects directly to a user’s GitHub or Bitbucket repositories and Jira projects to ensure data privacy and security. Any action performed on the Anaxi applications is written back on GitHub, Bitbucket and Jira to maintain consistency across projects involving multiple team members.

    At its core, Anaxi is pulling metadata from DevOps tools to apply analytics to track individual developer productivity and team performance. IT leaders can, for example, analyze how much code has been added and removed, refactoring and code churn on a weekly basis. Anaxi can be used either in place of a project management application or as a complement to an existing project management tool to make analytics more accessible.

    The primary goal is to make it easier for IT leaders to identify DevOps bottlenecks and prioritize projects in a way that advances business goals. Too many organizations are writing more code than ever only to discover projects are being held up because a single component on which every other module depends is behind schedule. Many of the developers writing that code could have been working on other projects if IT leaders had been made aware of changes that needed to be made to the schedule based on the anticipated delay to another project. Anaxi essentially applies predictive analytics to software development projects to determine based on past histories the likelihood of a deadline being met, Verstaen said.

    Armed with that intelligence, IT leaders can either proactively reallocate how resources or allocated or inform business stakeholders to changes in delivery schedules. In either case, Versaten says the goal is to enable IT leaders to avert any software development crisis that might arise.

    The Anaxi app is free to use by teams of up to 10 members. Teams of more than 10 users will be required to adopt a premium plan priced at $19 per month per user.

    — Mike Vizard

  • 5 Guaranteed Ways to Kill DevOps Developer Productivity

    5 Guaranteed Ways to Kill DevOps Developer Productivity

    “A developer is an organism that turns coffee into code.” I still laugh when I see that quote as it reminds me of my hardcore developer days, when my cube always seemed to be directly next to the coffee machine and caffeine was management’s way of ensuring we had the energy to develop well into the wee hours of the evening.

    What is developer happiness? I like to believe it hasn’t changed dramatically over the years. It’s about giving developers the right tools and the freedom to do what they do best—produce meaningful code. That means reducing distractions so they can meet or beat expectations and timelines, ultimately driving revenue for the organization.

    I trust your company is not in the practice of molding reusable human coffee filters. But are you doing everything you can to help your developers be as satisfied and productive as possible, or are you taking the “necessary” steps to ensure they are buried in context-switching hell?

    If the latter is your aim, read on to learn about five guaranteed ways you can totally kill developer productivity.

    Saddling Developers With ‘Plumbing’ Work

    Companies frequently look at developers primarily as technical resources instead of true innovators, so they get saddled with plumbing work. In DevOps and continuous delivery (CD), that’s writing a lot of ad-hoc scripts to string together pipelines, define infrastructure and manually create deployment plans. If your company is on the road to cloud adoption, it’s imperative to get unnecessary scripting under control because things only get more complicated as you start to incorporate the many different cloud platforms and services that are available.

    Making Developers Deal With Security After the Fact

    A fail-safe way to kill developer productivity is to make them deal with security after a release has left development. Too often, they first build code, QA then tests it and finally someone from security checks it to make sure there are no holes well after the code has been written. If security problems are found after coding is done, the release is halted and must go back to the developer to fix. This often occurs either just before the production release or, worst case, just after. In either case, not only does it take longer to resolve the problem, it also prevents the developer from moving on to the next big thing.

    Expecting Them to Chase Down Features and Status Requests

    Because development pipelines are often not integrated with the higher-level CD pipeline, those outside of development have no way of seeing the status of features, deployments and releases. Understandably, their only option is to ask developers to provide status information or call a status meeting which, of course, are additional interruptions that divert them from feature development. Developers don’t like it, and it doesn’t exactly help anyone else in the pipeline be more productive, either.

    Bogging Developers Down With GUIs

    GUIs are a great democratizer in large organizations. They offer a user-friendly way for people across the company, regardless of technical know-how, to access the information they need to be productive. But many developers see them as a waste of time. And while even the most GUI-resistant developer needs them every so often, they are not their preferred way to work.

    Taking Away Their Favorite Tools

    Standardizing your software delivery process is a must to increase efficiency, but standardizing on tools is not. Taking away their favorite tools is highly recommended only if you’re keen on decreasing developer satisfaction.

    What are the Alternatives?

    Managers and leaders can help developers by taking as much of these mind-numbing tasks off their plates as possible. They can do that by automating the release process and integrating CI pipelines into the CD pipeline. Doing so allows everyone to plug in to what’s happening in development without having to interrupt developers, and they can continue to use their beloved tools and simply connect them into the release pipelines.

    It’s also important to standardize most of your operations work upfront—infrastructure, provisioning, compliance, security. All this advance work will allow developers to consume environments on-demand and just deploy without extensive scripting or re-scripting for changes and maintenance.

    Keep in mind, if you shift security left, closer to the development process, you need to automate it. Otherwise, it becomes someone’s manual task—a developer, DevOps engineer or security person—and that will slow down the delivery process. For example, SAST test and SCA scans can be automatically run on every check-in. DAST tests can be automated to run after each build. This way, any security holes are caught as early as possible, while the code is still fresh in the developer’s head.

    Finally, reduce the amount of work developers need to do through GUIs. Give them a way to kick off releases from their respective CI pipelines and the ability to define release pipelines—infrastructure, configuration, security and so on—in code.

    Coffee Machine or Barista?

    Doing these five things—relieving developers of unnecessary scripting, standardizing compliance requirements and security checks upfront, reducing the need for developer-provided status updates, enabling them to work in code and allowing them to continue to use their favorite tools—will make the difference in whether your developers feel like the office coffee machine or a master barista.

    — Dan Beauregard