devopsy.kinsta.cloud

Category: DevOps Culture

  • ZenHub Brings More Science to Sprint Planning

    ZenHub Brings More Science to Sprint Planning

    ZenHub today revealed it has added a Planning Poker capability to its platform for managing software development projects that is designed to make it possible to prioritize sprints based on feedback collected from members of the application development team.

    That capability extends a sprint planning capability the company added this year to a project management application designed specifically for software development teams that employ the GitHub software repository. That sprint planning tool also automates routine tasks, such as automatically carrying over unfinished work to the next sprint.

    Aaron Upright, head of strategic accounts for ZenHub, said collectively, those capabilities will make it possible for development teams to prioritize their efforts in a way that is less biased using points that weight the opinions of team members based on how accurately they have made previous forecasts. For example, Planning Poker will assign a different weight to a developer that is consistently either overly optimistic or pessimistic about the length of time required to complete previous projects.

    Planning Poker is built right into GitHub, which Upright noted allows developers to make estimates without having to exit an environment where they already spend a good portion of their day.

    Thanks mainly to both an increase in and acceleration of the digital business transformation initiatives organizations have launched, DevOps teams are under increased time constraints.

    Many organizations’ entire business strategies now revolve around the rate at which software development projects can be completed. Many elements of those projects can’t go forward until a specific component upon which it depends is completed. Investors are holding business leaders more accountable for software delivery timetables that have direct implications on revenue generation.

    Not surprisingly, the type of end users that are now accessing project management applications to keep tabs on development progress has increased. Everyone from the sales team to the board of directors now wants more visibility into the rate at which software development projects are being completed. The challenge DevOps teams face is software development is an inexact science. Developers, based on individual personalities, exacting standards and willingness to work extra hours, are going to have widely divergent opinions on how long it may take to complete any given sprint.

    Nevertheless, Planning Poker presents organizations with an opportunity to rely on a more scientific approach than traditional guesswork, said Upright. The simple fact of the matter is that all estimates are wrong. The goal is to narrow the margin of error, he added.

    Regardless of how application development projects are managed, the relationship between DevOps teams and the rest of the organization has fundamentally changed. The entirety of some organizations is wholly dependent on the speed at which high-quality software is developed. In many cases, expectations are not realistically aligned with available development resources. A project management application that is widely employed across an organization should make that apparent to all interested stakeholders, which, in theory, at least, should result in either the hiring of additional developers or reassessment of the business strategy before the existing development team simply decides to abandon ship altogether.

  • Best Practices for Building Next-Gen Software Teams

    Best Practices for Building Next-Gen Software Teams

    Technology is moving faster than ever before. The pandemic has accelerated digital transformation across every organization in every industry. Creating new remote working environments or developing new digital revenue channels has taken place at lightning speed over the past year.

    At this time of rapid change, software development teams are continuing to help organizations adapt to our new environment and stay ahead of changing consumer habits. They also have to deal with their own personal situations and shifting organizational priorities – from new COVID-19 protocols to virtual offices.

    As 2021 progresses, what are the elements that can help business leaders stay ahead of the latest innovations and build resilient, forward-looking teams? Here are three tips I believe will help build next-generation software development teams.

    Put Your People First

    Finding the right people is never an easy task. Hiring for the skills you need to fill a role is important, but it’s also necessary to look beyond those requirements. Having the right technology skills is not always the be-all-end-all when it comes to hiring. Is this candidate a good fit from a cultural standpoint? Will they be engaged and motivated? Are they interested in learning and growing their own skill sets? Do they have different experiences and perspectives than your existing team members? Each team member brings something special to the table, and treating each person as an individual and as an essential part of your larger operation is crucial. Everyone should feel valued and connected to the company. This is especially true during the pandemic. Managing with a sense of empathy, understanding, and caring helps team members feel a sense of belonging and as though their job matters – because it does. When employees feel that their role is undervalued or unnecessary, they can easily become detached and uninterested. Hiring for the person and caring for your people during and after work hours builds better teams and keeps them connected to the business and mission.

    Allow Software Teams to Experiment

    Staying ahead of the latest trends and technologies is critical for delivering advanced software. Experimenting and allowing your teams to try new things can go a long way to drive innovation. It gives them opportunities to learn new applications and ways to deploy new technologies. Continuous training is a key part of the experimentation process. Our teams, for example, actively participate in more than 20 events per month. We also invite clients to join and participate, adding another layer of value for our clients. These events come in different forms and settings. They are virtual, gamified and often employee-led. The idea is to create space for open-minded discussions, team-building exercises and knowledge sharing. For example, our head of digital security leads regular sessions to educate our people on evolving security threats and effective security strategies to defend against them. Adapting to new ideas and building expertise in new technologies require a “no fear” mindset. Having the freedom to experiment and learn from each other provides the framework to keep teams ahead of the latest digital trends.

    Empower Your People

    Giving team members a certain degree of autonomy and responsibility for decision-making in their daily work improves innovation and productivity. When you empower employees to make their own decisions and decide their own path to success, you create a better workplace culture. At Cinq, for example, all one thousand of our developers know what projects we are engaged with across the company. Not only are they aware of what’s happening, they know the project goals, objectives and KPIs of every client engagement. Team members can request to be added to certain projects and teams at any given time. They may be interested in the client’s business, want experience with a new application or have an idea or suggestion to help us achieve our goals. We also give them the tools and resources needed to successfully manage or lead their own projects, which can lead to massive innovations inside our own business. Empowered employees are loyal, committed and more productive. When employees are given opportunities to work toward their goals and drive their own careers, the benefits are enormous.

    Staying ahead of new technologies and applications can be a challenge for even the most tech-savvy organizations. Recruiting motivated learners, empowering your employees to move across teams, and creating opportunities for experimentation are critical elements to building next-generation software development teams.

  • Will App Dev Become a Normal Competency?

    Will App Dev Become a Normal Competency?

    With a shortage of available developers, companies are considering low-code methods to meet massive application development needs. As a result, by 2024, citizen developers will be responsible for 65% of applications, Gartner predicted. So, if technical ability rises across the board, will application development become an expected skill set for tomorrow’s digital workers? And if so, when?

    “Application development will become a normal competency,” said John Bratincevic, senior analyst, Forrester. Bratincevic recently gave a talk at the Rethinking “How” into “Who” with Low-Code event, presented by TrackVia.

    I asked Bratincevic to dive deeper into how application development is becoming democratized. In short, the low-code movement has permanently altered expectations around who can be involved in application development. To him and others within the industry, leveling up with citizen development knowledge could be vital to retaining a competitive advantage in the future digital-native workplace.

    The Undigital Condition

    As more and more companies digitally transform, they are evolving into software companies. In this new paradigm, “software is an expression of the business,” says Bratincevic. Yet, most organizations have not entirely digitally transformed. According to Forrester’s Q1 2020 Global Digital Process Automation Survey, 76% of companies still rely on paper-based processes, and 94% use Excel or email-based processes.

    Unfortunately, developer talent is too few and far between to rectify this “undigital condition,” and existing IT teams are struggling to keep pace with demands for more software-based processes. Too often, teams are told to get in line and wait for experts to develop software when they can, said Bratincevic. This gap results in a less adaptive structure that limits new ideas.

    “All organizations are probably, to some degree, adaptive, but their improvement and adaptation are typically only periodic and conducted by specialists,” wrote Mike Rother, Toyota Kata. “In other words, such organizations are not, by their nature, adaptive.”

    A New Generation of Citizen Developers

    The old model is not realistic anymore, said Bratincevic. Instead, a new generation of citizen developers could use no-code and low-code platforms to program operational tasks themselves. These tools use visual, declarative techniques instead of programming and are “empowering employees outside of IT to deliver apps,” Bratincevic said.

    So what is the demographic behind citizen development? Reports show that younger, digital-native employees are more likely to use low-code platforms. According to the TrackVia report The Next Generation Worker: The Citizen Developer, 50% of citizen developers are 18 to 29 years old. The study also found that citizen developers are 13% more likely to expect promotions, correlating citizen development experience to career advancement.

    In this projected economy, “digital elites” seem well-positioned to progress, whereas others are in dire straits. “Knowledge workers with simpler, more focused roles (e.g., a “coordinator”) and without digital skills are at risk,” said Bratincevic. Thankfully, low-code could offer a practical way to enter the tech field and increase job security.

    Leveling Up From Productivity Tools

    Today’s average worker is quite familiar with personal productivity apps such as email, social communications, calculations and other consumer technologies. Just as productivity tools have become commonplace, Bratincevic predicts that application development will become a standard skill set in the future.

    Other IT leaders agree that coding literacy will soon become ubiquitous. Apple CEO Tim Cook, for example, recently emphasized to the U.S. president that “we believe strongly that it should be a requirement in the United States for every kid to have coding [education] before they graduate from K–12 and become somewhat proficient at it.”

    Application development may become a typical proficiency; however, the exact nature of software development is up for debate — especially as development environments add more abstraction layers to the lower stack that only involve programming languages indirectly. For example, Bratincevic describes how those learning to code often use a service like code.org, which involves low-code tooling and games to help educate students. “I see the same pattern for the adult professionals in the workforce,” he said.

    Future application development may not even resemble programming in the traditional sense. “Once ‘development’ on these kinds of tools becomes ubiquitous, we may not even call it application development anymore,” Bratincevic said. “It will just be — work.”

    Goals for Citizen Developer Programs

    According to an Outsystems report, 20% of companies adopted low-code to enable citizen developers to construct applications. “One of the main reasons firms are buying low-code is to enable non-IT folks to develop,” noted Bratincevic. “I routinely get inquiries from enterprises who are looking to accomplish this very thing, at scale in their organizations.” In particular, he notes apps of substance being created within health care, vehicle manufacturing, oil and gas and insurance industries.

    It appears more and more organizations are sanctioning a new wave of citizen developers. So what goals should these new citizen development programs aim to achieve? Bratincevic shared the following benchmarks:

    • Digitize. Everything. Always: Foster a digital problem-solving culture and develop a digital workforce.
    • Balance autonomy and control: Citizen developers shouldn’t have to ask permission to make a spreadsheet. Yet, guardrails are necessary for more far-reaching programs.
    • Take charge as privateers: He recommends organizations start by adopting an autonomous, business-led team, which he calls a Privateer model.

    Low-code could also help bring shadowy, rogue IT to light and rehabilitate it in a sanctioned way.

    The Era of Low-Code

    In 2021, the low-code market is estimated at $13.8 billion, said Gartner. SD Times even coined 2021 the “year of low-code.” But, since the citizen developer movement has permanently raised the bar, I would edit this statement to say we have entered the era of low-code.

    For more information and case studies on citizen development, I recommend watching the panel webinar Citizen Developer Movement with Forrester: Rethinking “How” into “Who” with Low-Code. In addition to John Bratincevic, it features Dave Garret, chief strategy and growth officer, PMI, (who I’ve spoken with in the past on How To Foster a Culture of Citizen Developers) and Joshua Yaklin, SVP of operational risk, Stearns Lending.

  • DAOPS Meetup 2021: Software Engineering, DevOps and DevSecOps

    DAOPS Meetup 2021: Software Engineering, DevOps and DevSecOps

    DAOPS Foundation—a non-profit organization committed to accelerating global digital transformation through technical standardization—is hosting the first ever DAOPS Meetup on May 18. The virtual meetup will bring together DevOps leaders from Sonatype, DevOps Institute, TARS Foundation and DAOPS Foundation to discuss the latest in software engineering and the latest DAOPS developments.

    Here are the four sessions scheduled for the DAOPS Meetup.

    ASEM, Next Generation Software Engineering Infrastructure

    Software is the core of digital transformation. In the digital era, the way we produce software also needs to be digitized. Forest Jing, chief evangelist at DAOPS Foundation, explains how they plan to help global enterprises build a high-performance, technical organization based on Lean, Agile, CI/CD, SRE, DevSecOps, Cloud Native, etc., by developing the next generation software engineering infrastructure named ASEM.

    Best DevOps Practice with TARS

    TARS is a high-performance RPC framework based on name service and Tars protocol, also integrated administration platform, and implemented hosting-service via flexible schedule. During this session, Mark Shan, chair at Tencent Open Source and TARS Foundation, will share the best DevOps practice using TARS.

    DevOps Hybrid Skills — Upskilling towards EverythingOps

    Upskilling is a human endeavor and a key contributor to personal and career growth. This past year was like no other. As we progress through the “next normal” of this decade, one thing is certain—digital transformation relies on human skills transformation. DevOps has continued to shift left in recent years, becoming more integral to operational processes as manifests in domains such as secure-development-focused DevSecOps, secure-operations-focused SecOPs, artificial intelligence-based AIOps, machine learning-focused ModelOps, and data management-related DataOps. As each of these evolves, its specific required skill set is being fleshed out and internal IT staff have the opportunity to upskill to meet requirements. Join Dheeraj Nayal, global community ambassador at DevOps Institute, to learn all about DevOps upskilling.

    The Rise of Next Generation Software Supply Chain Attacks

    Cameron Townshend, Solution Architect from Sonatype

    The adoption of open source in software development has grown exponentially over the past decade. Yet, the time required for hackers to exploit a newly disclosed open source vulnerability has shrunk by 93.5%. As development teams deliver new innovations, adversaries are also upping their game; something we’ve seen in recent high profile and devastating cyberattacks, such as Dependency Confusion.

    Adversaries have the intent and ability to exploit security vulnerabilities in the software supply chain—and in some cases plant vulnerabilities themselves. They have increased scale through automation and improved breach success through precision targeting. Cameron Townshend, solution architect at Sonatype, urges developers to fight back by doing the same: automating security directly in the DevOps pipeline.

    For more information and to register visit the DAOPS Meetup website.

  • Why DevOps Needs Mandatory Vacations

    Why DevOps Needs Mandatory Vacations

    “If a team doesn’t have time for retrospectives, you should hold them twice as often.”

    It’s 5:00 p.m. on Friday, and you’re just shutting down your computer to kick off the weekend. A message pops up in Slack:

    “Congratulations, you’ve been selected to take the next week off! We’re cutting off access to all work-related systems and revoking your credentials for the week. See you the following Monday.”

    What just happened?

    There’s an ancient security practice worth reviving in the age of DevOps: mandatory vacations. In practice today, it typically looks more like cutting off access when an employee is taking an already planned vacation, rather than forcing them to take a spontaneous one.

    But the goal remains the same: quickly assess bottlenecks, critical dependencies and security vulnerabilities. The side benefit? Your employees actually disconnect completely when they go on vacation!

    The Double-Edged Sword of DevOps

    DevOps practices increase a team’s end-to-end ownership, responsibility and autonomy. Team members modify code, deploy infrastructure and handle operational duties – sometimes all in the same day. Bringing Dev and Ops teams closer together results in reduced lead time, faster deployments and higher-quality software.

    But blurring the lines between Dev and Ops requires broad access and permissions. When everyone on the team has access to everything, there’s no forcing function to prevent relying on individual or shared accounts. This access proliferation results from a lack of clear indication on which credentials, accounts or permissions authorize each responsibility. Critical tasks may depend on a single person’s account. Credentials may be shared and never rotated.

    For example, deployment may depend on a service account, or bot, for which everyone has a copy of the API token. Admin or sudo rights may be delegated on a case-by-case basis to individuals, rather than role-based access control or group management.
    The result: a confusing quagmire of roles, permissions and dependencies.

    Reviewing and Remediating

    Explicit review of all accounts and permissions is an onerous, audit-like chore. While it might be necessary, particularly in regulated environments, it doesn’t mesh as well with agile, iterative, automated and just-in-time principles that fuel DevOps.

    Mandatory vacations provide an alternative. It’s a simple concept: cut off a team member’s access when they go on vacation.

    Depending on your setup, you might use this time to disable accounts, revoke privileges, rotate credentials, remove them from groups and even archive any home directories left over in production.

    The danger lies in leaving dependencies on personal accounts for day-to-day operations. From a security perspective, personal accounts are much more likely to be compromised or abused by a disgruntled insider. They’re an automatic back door into your deployment and production systems. From a reliability and operations perspective, a dependence on personal accounts means that changes to personal accounts (such as an employee leaving or losing access) may cause unforeseen outages. When you control the change as part of a mandatory vacation, you’re prepared for a change that could potentially cause things to break and can trace it back to the root cause quickly. Nothing like breaking the build to force a cleanup of technical debt! This technical debt could include critical nightly cron jobs left in home folders or owned by a single user, personal credentials hidden away in build secrets or operational practices that were assuming an individual’s identity or role.

    As a bonus, mandatory vacations also help ensure you keep your on-boarding practices up to date and robust. While re-provisioning your well-rested colleague upon their return, you are forced to acknowledge which privileges and permissions are truly necessary. Depending on the team’s growth and maturity, that may mean creating well-documented practices or enabling full user management automation.

    Finally, this provides an opportunity to promote key security principles. Are you enforcing least privilege where you can, giving users the minimum level of permissions needed to do their job? Are you granting access to shared folders in your password manager? If so, did you rotate the stored credentials when your colleague “left” the company, however briefly? This might provide an excellent example of why it’s time to implement multi-party authorization (MPA), just in case gaps like these persist, even after a few mandatory vacations.

    Mandatory vacations provide a ‘testing framework’ for access proliferation. Repeating difficult agile practices frequently helps streamline the process simply by doing it more often. If your team doesn’t have time for retrospectives, you should hold them twice as often. Testing your access management practices every time a colleague goes on vacation provides a natural, easy cadence to ensure your practices remain up-to-date – without having to scramble after a breach or when a team member leaves permanently.

    Take a Vacation, for Everyone’s Sake

    You might think you don’t have time to deal with the ramifications of random mandatory vacations. But imagine how much more difficult it is to discover a single chokepoint during a live incident! If you don’t have the time to test off- and onboarding accounts, that implies your access management practices are rusty, poorly defined and thus, unavailable when they’re needed in a rapid-response scenario. Laptops and accounts will be compromised. Staff may leave or join for unforeseen reasons.

    So please, take a week off … for your sake, and ours.

  • Empowering BizDevOps Teams With SLOs

    Empowering BizDevOps Teams With SLOs

    When BizDevOps teams are drowning in logs and false alerts and are spending more time on manual processes than on building and deploying new applications and features, the work suffers, morale suffers and the organization as a whole suffers. Releasing better and more secure software, faster and with real business impacts starts with a robust BizDevOps practice. A crucial step IT leaders can take to align the developer, operations and business teams is to create a shared language of service-level objectives (SLOs).

    SLOs are metrics for validating that software is meeting its technical and business objectives. Defining and implementing SLOs help align developer, operations and business teams, not only ensuring everyone is moving toward the same goals, but also providing a way to reliably measure how BizDevOps teams are progressing toward these goals.

    Here are three of the most impactful ways SLOs can empower your BizDevOps teams.

    1. Establish a Common Language Across the Delivery Cycle

    The best SLO gives you precise and actionable insight into your system. Take performance and resiliency engineering, for example. By defining SLOs for performance and error rates, teams can use common measurements to track progress toward meeting their quality criteria to ensure they are staying within their error budget.

    In this way, teams can use SLOs as a common language across the delivery cycle – something everyone from developers to operations to business teams can rally around, ensuring everyone is working toward the same outcomes. This aligns teams into a coordinated BizDevOps practice, where all sides have better insight into how each piece of the business feeds into the others. If an incident occurs, operations can use an AI-based observability platform to observe its trends and impacts across different product or service releases and automatically feed that information back to the developers, who can modify their builds accordingly. When everyone is using the same SLOs to speak the same language, BizDevOps teams can coordinate and communicate more easily and effectively.

    2. Creating a Culture of DevOps Resiliency by Shifting SLOs Left

    BizDevOps isn’t just a technical practice defined by tools and platforms. It’s also a culture change and a shift in mindset. SLOs can play a major part in this change. Shifting SLOs left into the delivery pipeline means giving developers feedback about the outcome of their work and real-time visibility into their business KPIs using consistent SLO measurements – ideally, on every code commit. This consistency gives them answers at their fingertips to make data-backed decisions that consistently deliver better business outcomes. Using SLOs for developer feedback is a fundamental building block of DevOps, but it’s also key to creating a culture and mindset of resiliency within BizDevOps.

    A resilient BizDevOps culture is more than just making changes to your technology stack; it’s about changing the mindsets of individual engineers and developers. Resiliency means strength and reliability; the trust that when something goes down, it’ll go right back up. It’s about building the processes and systems that guarantee flexibility for anything from managing crisis events to delivering service continuity. Shifting SLOs left helps facilitate this culture change by giving developers greater exposure to the impact their work has when it’s in production and when it’s deployed. It makes everyone feel they’re in the same boat, and recognizes developers, operations and the business teams as one cohesive unit.

    3. Integrating SLOs Into Remediation

    BizDevOps teams can use SLOs to enhance remediation and incident response efforts. With everyone working with the same metrics, BizDevOps knows with certainty when something is broken, can identify root causes more quickly and can develop agreed-upon incident responses to accelerate time to resolution. BizDevOps teams can then feed this incident response knowledge back into quality gates earlier in the development cycle to avoid future problems. This develops SLOs that have been “battle tested” and can be easily automated to make quality gate testing better on the development side, and incident response better and faster for the operations side.

    SLOs bridge the gaps between BizDevOps

    SLOs already serve a useful role in production, but they also can influence the ability to create a robust, resilient BizDevOps practice. Shifting SLOs closer to developers and using them as a shared language across the delivery cycle provides space for greater experimentation, more innovation and a culture of resiliency. SLOs can also be defined along business-relevant metrics, such as conversion rates, user experience or feature adoption. As a result, SLOs empower BizDevOps teams to respond more quickly to issues and deliver better digital experiences and business outcomes.

    SLOs aren’t just performance metrics – they’re a powerful tool for bridging the divides between the developer, operations, and business teams. SLOs can help cultivate a BizDevOps culture that delivers innovative, secure software faster and with tangible business value.

  • Five Tips For Creating Design Systems

    Five Tips For Creating Design Systems

    Design systems were all the rage half a decade ago, with an explosion of open source resources made public by Google, Salesforce and Shopify, for example. Not long after, design tools like InVision, Sketch, Adobe XD and Figma featured ways for product teams to maintain design systems within their apps. If you want to build a scalable, consistent product that increases build velocity in design and engineering teams, a design system is integral.

    Throughout my own design career, I have become an advocate for building and maintaining design systems. It has become a niche passion of mine, and I hope to share some of what I’ve learned through the years as a design system nerd.

    But wait – first, what is a design system? A design system is a library of style, components and other patterns documented so that building and adopting products is more efficient and cohesive for designers, developers and end users alike.

    The key benefit of a design system is that it creates consistent, repeatable patterns that make end users think less. A product experience that delights is usually designed with persistent visuals and consistent interaction. Users want to feel comfortable knowing that no matter where they navigate, they won’t be surprised by what they find. Repetition, in the case of product design, is not boring, but welcome. Design systems create trust with users.

    Another benefit is the increased build velocity from design and engineering teams. As designers, we are tasked with solving problems. We want to create a simple understanding of how our users can accomplish tasks in a workflow. Of course, we are tempted at times to invent new patterns to solve design problems. We often forget, in the minutia of design iterations, that we’ve already solved a particular problem in a prior project or in another part of the current product. This inefficiency can lead to wasted time, especially if those existing patterns and components have not been documented. In a single-person design team, the negative effects may not be as visible, but one can imagine the exponential nature of a larger design team consistently duplicating existing work or creating new patterns that, ultimately, create an inconsistent user experience.

    Instead, we want to empower ourselves as designers to focus on solving problems without the need to invent new interfaces every time we are posed with a design challenge. Design systems are always vital, but are especially so when design teams scale up and the product experience reaches a level of maturity.

    Hopefully, you’re now convinced that design systems are the backbone of the best design teams and delightful user experiences. Below are a few tips to help you create a usable design system in your own organization.

    Start Small

    Create that button symbol. Save that primary color or header text style. Audit your designs and see what patterns emerge. You get the idea! It doesn’t matter where you are in the design process; any remnant of documenting a pattern will do wonders for saving your precious time and creating beautifully consistent experiences for end users.

    Prioritize Design System Documentation

    Whether it’s as simple as a shared page, internal minisite or a full-fledged website, documenting your design system and making it easily accessible to the right people is fundamental to its success. You need to determine the level of complexity that is needed for your organization and teams that you collaborate with. Talk to your engineering team to see how to best document and stay in sync between design and code.

    Keep Evolving Your Design System

    Ask yourself and your team if certain parts of the design system are actually helping solve problems. Iterate on a component that needs to be more flexible or add a new one if there is an important use case that needs to be addressed. Audit your component library to see if there are components that are not used, or if there are multiple components that can be merged.

    Have a System for the Design System

    It’s easy to get lost in the moment and forget to create an important, requested component or remind a developer to build a part of the UI as a component. Having a project management system and workflow for your design system can help prioritize needs and keep communication organized. Whether it’s logging tickets in Jira, moving cards over in Trello, or simply annotating or resolving comments in Figma, there needs to be a workflow that is consistent and works for the entire team.

    Collaborate

    I’ve fallen into the trap of being inside a design tool bubble. As designers, we’re often stuck inside software that is great for communicating a user experience but poor at staying in sync with the actual code that is being written. This causes an inconsistency between design and code. Design systems are no exception to that problem. From the outset, advocate for working with a developer to build a design system that works as a fruitful collaboration between design and engineering.

    These five tips will help you start creating a usable design system that will make your collaborators and, most importantly, your users, happy. Ready to get started?

  • Why Browser and API Testing is Shifting Left

    Why Browser and API Testing is Shifting Left

    For developers working with cloud-native technologies, software testing and quality assurance is a key part of product development. For most teams, testing has “shifted left,” so the quality of the code can be assessed as it moves through the CI/CD pipeline. This approach to quality assurance reflects the rise of DevOps and other modern development practices – developers today own their applications from end-to-end, and conducting testing early in the product life cycle is how they find potential bugs, save their organizations time and money and build products that delight their customers.

    More recently, developers have added end-to-end API and browser tests into their CI/CD practices, extending the scope of their testing and quality assurance practices. By testing how code performs on different browsers and how it interacts with important data sources, developers have added another layer of quality testing to the early stages of their development processes. This has brought added benefits to other “shift left” practices, such as unit testing and security testing, and has led to a new understanding of quality assurance.

    Traditional Approaches to QA Can’t Support the Pace of the Cloud

    As companies have migrated to the cloud and adopted agile development methodologies that align with DevOps practices, they’ve encountered conflicting priorities between releasing code quickly and maintaining the highest level of quality on each release. Traditional manual testing techniques were not built for agile workflows, but instead supported older waterfall methodologies, in which testing could be conducted as a discreet instance before code went to production. With agile development, having a specific team in charge of all testing right before production is not the most sustainable approach, as it hinders the rapid pace of development that the cloud enables. This is why testing is “shifting left” to earlier stages of the development process, and why manual testing is being done by people embedded within each engineering team.

    Cloud-Native Teams Have Shifted Left Into CI/CD Pipelines

    As part of these agile methodologies, companies have moved toward leveraging CI/CD practices to ensure code is always in a state where it’s ready to be deployed. As code moves through these pipelines, developers want to ensure they are able to catch bugs earlier in the development cycle. To do this, they’ve taken to testing earlier and more often.

    In particular, developers have increasingly recognized the value of end-to-end testing throughout their CI builds. API tests allow teams to verify end-to-end workflows by chaining HTTP requests and API calls, so they can validate all the layers of their systems from worldwide locations. Browser tests capture the user’s view during critical transactions, so teams can understand how UI changes are impacting web applications. Shifting both left into CI/CD pipelines saves time and money, as fixing a bug earlier in the development lifecycle is much less expensive than trying to fix it at the last minute, when it has grown in complexity and scope.

    It also means many issues are caught by the developers, without the intervention of another engineer manually validating their work. This reduces the number of cycles required to find a bug, allowing the code to be circled back to developers, fixed and re-deployed to a testing environment. When regressions are caught early, developers can focus on the details that will make the product great.

    Visibility of Metrics, Traces and Logs Drives Value

    Running browser and API tests in your CI pipelines is beneficial, especially when teams can correlate these tests with data from across their stack – front end and back end, application and infrastructure. With correlated metrics, traces and logs that can be accessed easily without toggling between different products, teams will have the full context necessary for both detecting and troubleshooting failed tests. Detecting the failed tests allows for the rollback of bad code before it goes to production, and the correlated full stack data can be used to troubleshoot and fix any issues not caught during the development stage. This creates a new culture of quality assurance, in which maintaining quality is a holistic process that involves every part of the development cycle, and draws on data from every part of the stack.

    Consistent Quality Requires Collaboration

    This change in quality assurance goes beyond the practice of shifting browser and API testing left, and represents a fundamental change in how engineering teams collaborate within an organization. Testing happens before code goes to production, continues with robust monitoring once code is live, involves data from across the stack and is the responsibility of teams from various parts of the business. With this collaborative approach, for example, a front end engineer can easily identify an issue in the integration of their latest changes with the way the back end APIs are structured. They can then engage with the back end team owning this service to collaboratively iterate and find the best solution to resolve the issue. It may start with a shift left, but, ideally, it ends with the removal of silos and the opening of communication channels among teams.

    Automated QA Delivers Customer Value Faster

    A fully operational approach to quality assurance means that issues are resolved faster, or even resolved while code is still in development, so they never become issues at all. This creates a virtuous cycle – fewer regressions means less downtime, which makes customers happy, and frees up engineers to build new products, which makes customers happier still. That baseline of reliability and customer experience enabled by effective quality assurance is what allows for new innovation that delivers value to customers.

  • The Evolution of SRE and Developer Roles

    The Evolution of SRE and Developer Roles

    As an industry, we’ve seen cultures and roles shift throughout IT teams — specifically, the role of ITOps site reliability engineers (SREs), various developer roles and the culture of DevOps. Most of these roles operated – or still operate – in silos, and didn’t understand (or care to understand) how each other’s role worked. More importantly, they didn’t know how to work together. But these roles are starting to overlap, driven by the increase in demand for customer experience and, subsequently, in intelligent observability, or observability with AIOps. Before we dive into the ‘how’ behind the overlap, let’s look at how each of these roles performs today.

    Developer

    While the specifics of what a developer does varies by project, the overarching responsibilities haven’t changed much since the introduction of the role. Simply put, developers write code to create and improve product functionality.

    IT Operations and SRE

    Traditionally, an IT operations professional focused on operating the code a developer put into production; aka keeping the lights on. However, we’re now seeing evolution of the role of highly skilled operations pro to that of an SRE who oversees automation and features surrounding the product, like CI/CD pipelines, infrastructure-as-code and the ability to monitor and observe the services and components within.

    QA

    Traditionally, QA would test the code the developer wrote and move it down the deployment pipeline. But we’re moving away from traditional QA. Now, the role sets up an automated framework for the developer so they can automate tests — similar to how the SRE sets up the CI/CD pipeline and observability framework to build, test, deploy, verify and monitor their code.

    DevOps

    DevOps has, in some cases, evolved from a practice and culture into a role. The DevOps engineer prepares the automation and the CI/CD pipeline for the developer to push out their code to test and, ultimately, production. But let me be clear – I believe the idea behind the practice of DevOps is that the practitioner does everything — they own testing frameworks, CI/CD pipeline and infrastructure. They own end-to-end product development and operation, so when anything does go wrong, they know exactly what to do, where to go and how to fix it.

    In the end, if a SRE can develop everything around the product code and knows how to fix the product — isn’t an SRE actually a developer? What if we have a really skilled developer who sets up the automation and observability framework to get their code from their keyboard to the user as quickly as possible — without breaking anything, of course — while also building and improving all the infrastructure and components surrounding the product? Isn’t the developer an SRE, or at least performing site reliability engineering?

    The short answer, in my opinion, is yes. And there’s one guiding force behind this amalgamation, this crossover; ultimately, this evolution: intelligent observability.

    The role of observability with AIOps

    Traditionally, and with the use of many tools, DevOps practitioners and SREs have had to — manually — battle floods of data coming in from all their endpoints, services and products. This can feel like a never-ending struggle. It can lead to a lot of toil and time spent on maintenance, when what developers really want is focused time to do what they love – write code, create and innovate. Not to mention, the result has a negative impact on the customer experience.

    But now, new tools are surfacing to support the everyday needs of SREs and DevOps practitioners. For example, intelligent observability, or AIOps, applied to observability data like events, metrics, traces, changes and logs, gives teams clearer insight into not only where complex data is coming from, but why an issue is happening and what action they need to take to resolve it. They can spend less time operating and more time innovating.

    As these roles continue to evolve, it’s important SREs and DevOps practitioners remain agile and willing to adjust to keep up with the latest technologies supporting their day-to-day workflow. AI can be the key to keeping the incident count down and the customer experience up.

    Looking Ahead

    If you’re currently in one of these roles, consider how you are practicing. Whether you’re a developer, a QA engineer, a DevOps practitioner, or an SRE, have you evolved your role to fit your company and customers’ needs right now? As these roles overlap with the application of intelligent observability throughout your development life cycle, it’s possible to deliver better products and fix reliability issues faster. It’s up to you to decide if you want to embrace the evolution of your role and intelligent automation or stay put and risk falling behind.

  • Developer’s Guide to Open Source Spring Cleaning

    Developer’s Guide to Open Source Spring Cleaning

    Spring is here, and after a year filled with record-setting digital transformation and its associated vulnerabilities, now is the right time to give the open source components in your codebase a refresh. For many development teams, today’s open source operations present a ‘mess’ that’s difficult to clean up; often, no one knows how many libraries, third-party components or modules are in use, not to mention their vulnerability status. This can create a significant source of risk and technical debt, making a spring cleaning that much more necessary.

    The good news is that there are some simple strategies and tools that organizations can implement to jump-start the open source spring cleaning process. Once implemented, these systems will help ensure that your codebase is kept up-to-date and clear of vulnerabilities.

    Organizing and Inventorying Open Source

    When embarking on your open source clean-up mission, an ideal first step is to take stock of what’s there. Gathering a list of all the relevant libraries and packages in your codebase, along with version information and where in your code they are used, should be your top priority.

    Decide to Keep or Toss

    There is a strong possibility that some of the components in your library contain vulnerabilities. Be sure to use online databases for a published list of vulnerabilities to easily identify which items may be past their security sell-by date. Consider which ones to update and which to remove altogether if they’re riddled with unpatched flaws.

    Polishing, Dusting and Refreshing

    Polishing your physical surfaces not only makes them look shiny but also protects them from damage caused by light, water or other natural elements. Digitally polishing your open source security posture should involve keeping your code base defended in a similar manner, which means making repeat security assessments as frequently as possible while also keeping the inventory up-to-date so your teams are always aware of what’s being used.

    As a last step in this process, consider dusting off any outdated or existing policy documentation. Give them a spring refresh, as well, so they can account for the changes not only in your open source database but for your entire development team. By ensuring developers are all on the same page regarding policies, responsibilities and best practices, you are effectively setting the stage for the next phase of operational success.

    Keeping Your Open Source Code Clean

    Sometimes a clean-up becomes more substantial than anticipated and requires some extra muscle. Implementing a dedicated tool to assist with this clean-up will not only make the process faster and easier, but it can also lead to fewer false positives and more accurate results based on your choice of reinforcements.

    Software composition analysis (SCA) tools can parse your codebase and discover the libraries, modules or frameworks that are in use, and automatically compare all discovered components against a vulnerability database. Your SCA tool needs two key things to produce actionable results:

    • Access to a curated, high-fidelity vulnerability database. Your time is valuable. It’s well worth getting the most accurate data you can, despite what may be marked “vulnerable” or “safe” in the public domain.
    • Insight into your code. Just because you are using a vulnerable library does not automatically mean your code is vulnerable. What method in the library is vulnerable – are you even using it in your code? If you are using it, are you passing a static value or some input-derived variable? This is a function described as the ‘Exploitable Path’, and it is critical to focusing your clean-up efforts.

    This process will provide a comprehensive list of the flawed modules in use and help you decide what needs to ultimately be kept and what needs immediate attention. With the right tools – and the right data – you can get an accurate, prioritized list of what open source components you should update or depreciate in your code.

    While embedding an SCA tool into your development process and workflow alongside your other build and security-focused tools is essential to stop the accumulation of more risk and technical debt, maintaining the quality and freshness of the source vulnerability data is also extremely critical. While retaining an up-to-date list of vulnerable components seems like a full-time job, baking an open source hygiene process into your workflow can be a key component of your database’s overall maintenance.

    Evaluating your open source components at build time – and then systematically scheduling reassessment scans to catch newly discovered vulnerabilities in previously ‘safe’ libraries – can bake an open source hygiene process into the developer workflow. This will serve to extend the “spring cleaning” mentality to a year-round endeavor. With the threat landscape continuing to rapidly evolve and vulnerabilities rising by the hour, implementing these simple practices could have a long-lasting impact on your open source infrastructure as it stands today.