staging-devopsy.kinsta.cloud

Tag: bug fix

  • How Developers Can Spend More Time Coding, Less Time Fixing

    How Developers Can Spend More Time Coding, Less Time Fixing

    I don’t think anyone became a developer because they loved to spend their time debugging. As frustrating as it may be, making sure your build works is critical—and this burden is now falling on developers. If your organization wants to deliver highly rated apps faster, building quality into the development cycle is imperative. Even though agile development has become a popular approach, it’s execution has a ways to go.

    A recent trends report in mobile and web development shows 25 percent of time is spent addressing a bug fix backlog. This can slow time-to-market and limit the amount of new features your company can roll out—not ideal when your top priority is to draw in new users and boost engagement to stay competitive. The good news is, the time spent debugging throughout the development cycle can be minimized. How? By shifting QA into the development process, you can spend more time coding and less time fixing.

    Mastering Agility in Practice

    The question for devs today isn’t whether they test, but when and how to do it best. We’ve all heard the vague, top-line answers before: “Adopt Agile development,” or, “Shift left.” The problem is, these terms and strategies can be challenging to execute in practice, especially without proper tools to make it happen.

    When we talk about “shifting left,” there’s still an important balance to be found as to which stage is right for dev teams to test—it can’t be too early, when there is nothing meaningful to test, and it can’t be too late, when the test batch pile is too big. Once your coding and testing processes are harmonized, you can effectively maximize your time and resources and get the job done faster and better.

    For development teams, if testing is done in bulk at the end, identifying the specific point in the build that needs to be corrected is like finding a needle in a haystack. When we shift quality left, defects are found earlier among a much smaller set of changes, and are therefore easier to fix. That’s why continuous integration (CI) calls for building, integrating and testing the system you’re developing upon delivery of even the smallest change.

    By testing continuously, uncertainty is reduced and feedback loops are made smaller, ensuring you’re building in the correct direction. The “shift left” trend is ultimately going to condense the dev cycle by getting quality back into the ingredient list. The earlier we deal with quality issues, the less focus is taken from our primary goal: building valuable, innovative technology.

    Find Tools that Mesh with Your Workflow

    Whether you use Selenium, Appium or Android Studio, new products need to integrate seamlessly into existing developer environments. Having to switch between building tools and testing tools is a big waste of time, and it’s unrealistic to expect a high adoption rate if the product is disrupting, rather than enhancing, your workflow. If you’re expected to shift testing into your development cycle, look for testing tools that seamlessly support the continuous integration of testing.

    Once your testing and building processes is aligned, the testing feedback and analysis becomes a new bottleneck. To minimize inefficiencies and feedback gaps, you need to carefully select tools that will improve visibility into build health, and help avoid batching up issues.

    Empower Developers to Satisfy Users

    At the end of the day, smaller batch sizes are only half the battle. No matter the batch size, quality only can be built in if it includes full test coverage, and if all the defects can be fixed in a way that actually meets user standards of quality.

    With tons of potential end user environments, injecting reality into the development process is crucial if you want to meet the high expectations of today’s consumers. With different phones, operating systems, levels of connectivity and apps running in the background, you never know what your apps will be put through once released. Leveraging stable test environments capable of recreating all potential user conditions throughout the developments cycle will maximize efficiency in development and accelerate the speed of innovation at your organization.

    Through a better delivery pipeline, mobile app and web developers are simply more effective. Once your test process is automated, aligned and maximized, writing better code can become your main focus. By taking a strategic, practical approach to shifting quality left—and giving developers the opportunity to focus on what matters most—you’ll see happier developers, and in turn, more successful businesses.

    About the Author / Paul Bruce

    Paul Bruce is Developer Evangelist at Perfecto, focusing on the value of quality and velocity throughout the software life cycle. He previously worked as an advocate for API development and testing practices and a full stack developer before that. He now writes, speaks, listens and teaches about software delivery patterns in modern enterprises and key industries around the world. Connect with him on LinkedIn and Twitter.

  • Fixing Flaws: Bridging InfoSec and DevOps

    Fixing Flaws: Bridging InfoSec and DevOps

    The Road to Creating More Secure Code and Interlocking two Traditionally Distinct Practices

    As DevOps continues to expand across verticals, including the financial and government sectors, security has become paramount in the minds of CIOs and CTOs. As such, more organizations have begun to integrate security early in the development process. While security always has been a theoretical part of DevOps, the number of breaches making headlines recently and costing many IT professionals their jobs has taught us that now it is more important than ever for companies to build security into each and every methodology and practice. “Build it in from the start” is a fitting mantra for any developer today—and even more so for his or her boss.

    Creating more secure code for products and platforms starts from day one in the planning stages, and some industries are doing it better than others. You must include security—not just in the end product and late development stages, but also throughout the life cycle. Organizations can do this by employing a defined methodology and unified tools that support that methodology, so developers make security not only a consideration for their end product, but something fundamentally baked into their build.

    To achieve this harmony between Development and InfoSec, developers and Operations staff must be included in decisions about tools, standards and methodologies that the organization will follow. They need to understand what requirements are coming down the road so they can recognize the need to address those requirements in advance, rather than than being caught off-guard by problems or issues after the fact.

    Build a DevOps Toolset with Dev, InfoSec Buy-in

    It’s important to recognize that the door swings both ways; InfoSec folks can’t simply give developers a laundry list. Developers must be able to communicate their needs when it comes to security, and also must take an active role in the security of their product.

    Part of the importance of this two-way street is recognizing the benefit of having developers involved in security decisions from the beginning. When Dev stakeholders are given the opportunity to participate in the purchase decisions of security tools at the outset of a project, they gain insight not only into the importance of incorporating that tool into their build as well as an understanding of what the capabilities of that tool are. After all, the most expensive part of application security is having to start from scratch because of poor initial planning.

    When it comes to tools and security, good security is not necessarily what you buy but what you build. A good place to invest is at the DevOps tool level, where developers can build a process and methodology that allows them to create secure code throughout the process. This is a crucial step that limits point-in-time testing after the product is built—which can lead to expensive re-engineering.

    Teach Teams: A Bug Fix is not a Security Risk

    One way to keep costs down and priorities straight when addressing security challenges is to keep security issues and bugs separate from each other. Bugs are bugs and we all want them fixed, but a flaw in a piece of software is not necessarily always a security risk and does not necessitate an immediate fix (despite what the stakeholders for that feature might tell you). Finding flaws certainly should be immediate, but the process of fixing those flaws should involve prioritization.

    This does mean, however, that evaluating flaws in a very timely manner is important, and one of the first questions you ask yourself when addressing potential flaws or bugs in your software product should be, “Does this pose a security risk?” If the answer is yes, you can quickly pinpoint the source of that risk and address it. The good news is that by doing this, you can greatly reduce the potential of your product having security risks you either a) didn’t know about or b) didn’t think were actually security issues. The challenge is that this is a constant and ongoing process. Be sure though, the benefits are well worth the time you’ll invest.

    Recognize Fixing Flaws is a High Priority

    It also can be difficult to balance the practice of fixing security flaws versus adding new features, particularly when developers are getting pressure from above to continue adding features and improving the end product.

    Again, you need to look at risk. By weighing the benefit of features against the risk of flaws, you will be able to make smart decisions for prioritization. For just about every software product out there, security flaws should be addressed before new features.

    It’s also worthwhile to consider the fact that bringing new features into a flawed environment is probably not a great idea. Not only does it mean you still have a fundamentally “broken” product, but that new feature may 1) not work as you expect or 2) increase the security risk further. If the second scenario is the case, now you not only have to fix the initial security flaw, but you also may have to reel that release back in—something you probably would rather avoid.

    It’s also important to remember that good tracking, knowledge preservation and collaboration let you pinpoint issues, understand dependencies and determine the trade-offs faster.

    Security is not an Option—It’s a Must

    If you are looking for inspiration on how to better incorporate DevOps security best practices into your development process, look no further than government, financial and pharmaceutical industries. These industries face heavier regulations than just about anyone when it comes to security requirements, so they are continuously delivering secure software. Not only do they have to include security in their development process, they also must test that security and have defined educational requirements for their developers. In this end, all of this leads to some of the best and most sophisticated security practices in all of DevOps. If you want to gain good insight into how you can improve your security and see some of the latest advances in software development security trends, these are the industries you should pay attention to.

    The surest way to provide a poor user experience and to compromise an organization’s success is to allow a security breach that could have been prevented with better foresight. That is why security best practices for DevOps (or rugged DevOps) are so important. By following the recommendations above and employing some of these tactics into your DevOps process, you can decrease risk for you and your company, and ultimately have more confidence in the success of your product.

    About the Author / Ward Osborne

    wardosborneWard Osborne serves as Information Security Officer at CollabNet and has more than 20 years of experience in Information Technology and Security Management. For the past 15 years he has focused on security integration and cloud security and has worked with dozens of companies of all sizes creating a culture of security and using security as an accelerator in business processes. Connect with him on LinkedIn and Twitter.