devopsy.kinsta.cloud

Tag: agile

Why Is QA so Important in Executing a DevOps Implementation Strategy?

In a rapidly growing global digital landscape, enterprises are facing many challenges. These include changing customer behavior and the need to be in line with the latest technology trends. To address these challenges and to stay up the competition curve, enterprises are adopting a slew of strategies. These comprise expanding the capacity of processes, quick quality checking and delivery of applications and timely marketing of the applications. This is where DevOps comes as a one-stop solution to the aforementioned requirements.

When it comes to assuring the quality of software applications, the Agile and DevOps model of testing is favored over the traditional waterfall model. This is because software applications need to be tested across a swathe of platforms—devices, browsers and operating systems. In the DevOps scheme of things, software builds are continuously integrated and deployed in the development pipeline by using test automation. It involves the development and implementation of new features along with the streamlining of processes.

What Is DevOps?

DevOps is an amalgamation of terms “development” and “operations” and is underpinned on four basic pillars—culture, tools, collaboration and practices. Combining processes and philosophies, the DevOps approach helps enterprises deliver quality builds in the SDLC. Here, development and operations teams no longer work in silos but in close coordination with each other. As a result, quality becomes a shared responsibility and a culture of accountability gains ground. DevOps implementation leads to the quick development and deployment of quality builds, faster solving of critical issues and engendering greater trust and confidence.

Let us understand the best DevOps implementation strategies to derive outcomes such as continuous integration (CI) and continuous delivery (CD). To begin with, getting the QA basics right the first time and every time should be considered as part of the strategy. This is due to the fact that in a pure DevOps ecosystem, the lines between development and QA are blurred.

Test Automation

Since the software needs to have an omnichannel interface with third-party applications to perform optimally, the test process should be automated. There should be a smooth QA-DevOps alignment to detect and mitigate glitches early on in the SDLC. Thus, DevOps testing may involve choosing automated tools that are either open-source or commercial.

Teams Merge

To derive DevOps transformation, the integration of the QA team with other technical specialists becomes important. The final DevOps team should adapt a culture wherein identifying glitches becomes a shared responsibility.

Metrics

Since DevOps testing is all about quick identification and fixing of glitches, the metrics should be defined at the beginning. It will help the DevOps team to stay focused on the challenges and requirements. This calls for the QA engineers to setup test requirements into the workflow and guide the team therein.

Virtualization

The software application should be tested across a slew of platforms—devices, browsers or operating systems. Since it is well-nigh impossible to test the codes for numerous users (during usability testing), the same ought to be created virtually. The QA team can virtualize every test requirement to emulate the behavior of software components. Moreover, it helps to do away with the need for dependencies and addresses constraints faced in interdependent environments.

Choose the Right Tools

To enable DevOps automation, the QA team should choose the right test automation tool. The main criteria for choosing the tool should be the team’s expertise in using it. The tool should offer the ease of writing the test script in a single programming language. It should allow the testing of applications across operating platforms and browsers.

Continuous Integration and Continuous Deployment

These are the outcomes of any DevOps methodology. DevOps continuous integration and deployment encompass adding code changes in a repository and creating automated builds. This leads to an early recovery from failures as well as testing and delivery of products within fast turnarounds. Continuous integration based on test automation leverages regression testing and a version control system when a new code is added. Further, DevOps continuous deployment is about the capability to add new features to the existing applications. This makes enterprises follow a user-driven improvement of software and agile approach.

Conclusion

With the quality of software applications becoming the final arbiter in making an enterprise successful, taking the DevOps approach is crucial. However, since the whole process is hinged on executing comprehensive quality testing, the QA basics should be done right.

— Akshaya Choudhary

January 14, 2020
Is COBOL Here to Stay? Five Signs IT is Ready to Modernize

With increased demands and challenges around compliance and regulations, plus growing expectations for IT to provide more value-added services, companies are looking for more flexible and collaborative options. Interestingly though, while some IT departments have updated legacy systems, COBOL code has continued to be a mainstay. In fact, COBOL just turned 60 and many are saying it’s here for the long haul.

There are a lot of reasons that make it challenging—or for some, unnecessary—to move away from the language, but there are also several clear signs companies and IT departments should know that indicate it’s time to make a change.

Here are five signs IT leaders should pull the trigger on modernizing their legacy environments.

You’re Constantly Worried About the Risk of Losing COBOL Expertise from Your Team

COBOL has more production lines of code than any other language in existence, with over 220 billion lines of COBOL today—or around 80% of the world’s actively used code. One of the problems is that many that are well-versed in COBOL language are also nearing retirement, and the amount of COBOL programmers entering the market is much lower than it was 10 years ago.

Author Glenn Fleishman put it best in his article on the subject stating “the language never died, though its early practitioners have faded away, and the generation of programmers who built systems towards the end of the predominant mainframe era in the 1970s and 1980s are largely near or past retirement age. It’s a slow-moving crisis with no crackling deadline, like Y2K, to focus the minds of Chief Information Officers.”

Pressure from Business Leaders to Take Advantage of More Agile IT Methods

Whether it’s cloud, DevOps or microservices, businesses want faster and more frequent IT delivery of new services to customers. In order to drive these results, embracing more agile methods of IT and developing a strategy that can support rapid application delivery is key. Moving to the cloud, integrating with Java or shifting to Linux requires open-based models that can handle legacy COBOL applications.

You’re Quickly Losing Your Competitive Edge Because of the Reliance on Dated Technologies

Direct and even indirect competitors are encroaching more and more in the industry and in new deals, and you feel as if your company’s position in the market is slowly declining. This may be a product of competitors’ willingness to open source systems that promote the business agility needed to react far more quickly to changing market dynamics and customer demands.

If they are modernizing their IT and investing in new technologies quicker than you are, it’s likely they’ll catch up to or surpass you quickly.

Your Confidence in Your Current IT Environment Is Extremely Low

No matter the modernization strategy you pursue, you should ultimately feel confident and peace of mind when it comes to your environment today and as you look to the future. Without flexibility, collaboration and a tailored approach however, the business will likely suffer and may be the reason for the growing insecurities.

For instance, if you’re interested in programming COBOL in some areas, but currently operate in a significantly pure native Java environment, a flexible and manageable solution is key. If you want to generate Java as the compiled object, the result will be inflexible static Java objects, rather than something flexible and extensible — and will require access to the Java source. That source is not nearly as maintainable as the source generated in the COBOL to Java conversion, but can be leveraged in Java-operating environments, and is much more flexible than other alternatives.

You’re Experiencing Vendor Lock-In

You’re wedded to an established tech company or consultants on-hand that seem like safe bets, but instead have caused you to miss the mark in being flexible and future-proof–not to mention are likely far over your budget to maintain. While transitioning to a new partner may seem daunting, conducting an assessment of your operational, infrastructure and application environment can provide a more comprehensive picture of the strategy that is right for the business, help manage the process more efficiently and ultimately cut unnecessary costs well before an exact migration or conversion path is decided on.

Although many organizations have run COBOL without substantial updates and issues for decades, the ability to solely rely on the dated technology is quickly giving way to a growing need for additional languages and more agile systems. If IT leaders are experiencing one or more of these issues now, waiting any longer to address them can result in much bigger problems in the future and considering a modernization strategy may be the better path to success.

— Cameron Jenkins

January 10, 2020
The Role of Developers in Digital Transformation

Developers are an integral part of digital transformation. They architect the modular systems that overcome legacy and build the applications and solutions that allow firms to deliver products and services in new and innovative ways. Yet, when it comes to business decisions, many organizations overlook their developer talent.

Developers come from a variety of different backgrounds, but it’s safe to say that most have studied computer science, engineering or mathematics in some form. Coming from these disciplines means they are inherent problem solvers, so giving them a seat at the table when it comes to discussing business goals is, of course, beneficial.

To ensure the business insights of developers can be unlocked, organizations should consider the following four points.

Encourage Personal Development

More and more developers are actively taking an interest in improving their communication and leadership skills, recognizing that these are important tools for career development.

Soft skills, for example, are key to establishing relationships internally, as well as communicating to external parties. At any moment, stakeholders may want to understand the workings of product teams, or it may be the case that a customer requires more attention when implementing a solution. In the former scenario, developers must become advocates for the business and the way they work; in the latter case they must ensure that they take an empathetic approach to end users.

Whether it’s learning new programming languages, getting to grips with new technologies, or developing soft skills, developers relish the chance to grow. Organizations that offer learning and development programs internally will likely attract developers who are both apt and keen to involve themselves in other areas of the business.

Keep Things Agile

Operating within an Agile framework gives developers and other members of product teams a chance to develop soft skills through scrum meetings. During a scrum meeting, each member of the team is given the opportunity to communicate openly about their challenges and devise solutions for other issues. This not only ensures a high level of transparency internally, it also allows business analysts to provide an accurate picture of progress to clients.

Sharing insights and troubleshooting in an open forum enables those with a natural inclination for leadership to establish themselves as effective communicators. The limited size of Agile teams also keeps things personal enough that each team member’s feedback can be heard and considered by their colleagues.

Agile software development brings disciplines together, encouraging an exchange of ideas and an expansion of knowledge. This is in stark contrast to the Waterfall method, where siloed teams hand off work with little communication.

With Agile, teams share responsibility, communicate and apply their disciplines in contexts outside those they are used to. In essence, Agile is the ideal way to establish a culture that enables learning and development on the job. This is much more practical than setting up a program that teaches soft skills and educates teams about other areas of the business, as these sessions can eat into work time and reduce productivity.

Be Clear on Requirements

It’s all well and good attracting the best and brightest developer talent, but in order to get the best from them, firms must be transparent about what is expected day to day.

Firstly, efficient code delivered in a timely manner should be the goal of every developer. Testing and QA will, of course, reveal issues, and no one is perfect, but developers must be mindful of the impact inefficient or inaccurate code can have on a business. Workarounds may get you past a problem, but this is not best practice and leaves the business exposed should a client pick up on it–especially if the workaround causes more serious issues further down the line.

Fewer bugs or defects means scrum meetings can naturally focus more on strategy and new initiatives that might help grow the business. Organizations should therefore establish best practices and coding guidelines to reduce the temptation for workarounds, ensuring code releases are reliable and ready for the production environment.

Developers must also be able to comprehend the requirement to work with designs given to them by design teams, as these will align with customer expectations. Being able to dynamically incorporate client feedback into the development process is also key, particularly for those working with continuous delivery and continuous integration pipelines.

An interest in emerging technologies is desirable, as is an eagerness to innovate new solutions using them, but so too is an aptitude to leverage rather than re-invent solutions. This helps to keep costs down and ensures a maximum return on investment in existing solutions.

Keep an Eye on the Future

Increasingly, the ease with which organizations can react to advances in technology will determine their long-term success. It is therefore in their interest to ensure developers have the freedom to learn new skills and explore new tools that might increase efficiency or unlock new offerings.

Advances in IoT, connected devices, augmented and virtual reality, AI and machine learning, blockchain and 5G networks are just some of the technologies opening up new challenges for firms and developers alike.

Developers with the skills to harness these technologies will increase their employability, allowing them to secure better positions and salaries. They will also be well placed to advise on wider business goals, positing new use cases and solutions and fueling innovation.

— Arun Ramachandran

January 10, 2020
API Security in DevOps: Are We Too Comfortable?

Postman performed its annual survey of developers, and as this survey and many other surveys have shown, developers are generally comfortable with the level of API security that their organization has implemented. This has been a consistent trend, with most developers being comfortable that they are protected.

The problem is most organizations also put API security and management in the hands of developers.

Knowing the rate of change going on in Agile/DevOps shops, and knowing the complexity of environment, I think this mentality is akin to the pre-WW2 French belief in the Maginot Line.

While API security is certainly a necessity, it is not managed in a vacuum. You really are only as secure as your weakest link, and there are a lot of links in an API-focused environment. User credentials, tokens, SSL, requesting apps and their authentication, (still) code injection concerns…The list goes on and on.

I’m never comfortable with the level of API security currently implemented in DevOps environments. And I think it’s dangerous for you to be. It only takes one bad code iteration for one of the client instances to be vulnerable. That vulnerability exposes every API the client in question has access to, no matter what is being used as access control.

In the end, APIs must trust someone, or they’re useless. And that someone is most often a server app running on an instance that your users connect to. That app most often has its own credentials. How are they stored? How are they protected? What code changes could impact that instance’s security?

API gateways and management tools, when properly configured, are a big help here, but they are not a panacea. Since incoming connections must be trusted at some point, and outgoing connections must be assumed clean at some point, when one of those two things is a wrong assumption, what do you have in place?

Here’s the scenario: User A has rights to call the ShowMeCriticalData API. This API is called from a server app running on instance B. The server app authenticates user A, then calls the API for him–either with his credentials (best case) or its own (bad for tracking problems). If instance B receives an update that makes it vulnerable to compromise, user credentials are still needed to call ShowMeCriticalData, which is relatively secure, as long as User A is protecting their credentials adequately. However, if the app running on instance B is proxying requests and using its own credentials, Instance B becomes a weak point and attackers could use the vulnerability to call APIs without authenticating users. Worse, if User A is careless with their authentication info, there is little an organization can do to stop at least some misuse.

API logging and review can be put in place to notice odd behavior by username, and offer early warning that a user has been compromised. But will only catch most issues.

Of course, there are smart people working on the whole array of API security threats from cross site scripting to authentication spoofing even into TLS weaknesses. But that work is only useful if we all remember that our security could be better. With knowledge that there are weaknesses, we can look for things to mitigate the risk. As you all know, if you have public APIs the risk will never be eliminated–the purpose of a public API is for people to use it, and that exposes it to hackers that seem to be more ingenious by the week–but minimizing the risk is worth the effort.

Being secure in your current situation means you’re not focused on making it better. With API security, particularly in the type of dynamic environment DevOps creates, this is a dangerous road to be on. Assume there is a fatal flaw, and work to reduce vulnerabilities at each access point into the overall system.

This also goes for APIs you don’t own. We rate limited an API that called out to Google Places to match up with our plan/budget for the project. Our app was never going to come anywhere near Google’s caps on usage, but should a portion of our infrastructure be compromised, we could potentially end up with a massive bill from Google because we called the API a zillion times in a month. Likely? Not really. Possible? Not after a few lines of rate-limiting code.

You all have made some astounding apps. Make sure they are astoundingly protected. Because both business and users are counting on it.

— Don Macvittie

January 8, 2020
Synack: DevSecOps Being Accelerated by Cultural Shifts

The 2020 State of Compliance and Security Testing Report from cybersecurity testing platform vendor Synack claims that some of the world’s largest organizations are encountering a significant cultural shift within their development teams, and that bodes well for those seeking to build DevSecOps teams. For the report, Synack surveyed leaders from more than 300 organizations representing a number of industries and verticals, including technology, government, health care, information technology and financial services.

According to the report, a large percentage of organizations and institutions are moving toward a rigorous, continuous testing model to ensure compliance. As part of this shift, organizations are utilizing crowdsourced security testing to achieve regulatory compliance and real security, with adoption expected to increase four-fold in 2020.

Perhaps those companies are being driven by numerous new regulations on the horizon, including the California Consumer Privacy Act (CCPA), PCI DSS 4.0, New York’s SHIELD Act and other proposed data compliance regulations. Or perhaps the shift toward continuous crowdsourced security testing is being driven by the failures some organizations have encountered with traditional security testing methods, which were performed less frequently and failed to keep up with the CI/CD (continuous integration/continuous delivery) pipelines that many organizations have embraced.

Simply put, Agile and DevOps application development and delivery methodologies were poorly served by the traditional, siloed security testing methodologies of the past. A realization that has driven many organizations to embrace the DevSecOps model, in which cybersecurity becomes part of the overall team, having equal standing with both development and operations team members.

Organizations pushing ahead with the DevSecOps model quickly realized that security toolsets and team member interactions must change to be successful. Synack’s research bears that out, and the report offers that the adoption of continuous security testing platforms is expected to increase by 4X in 2020.

“The rapid embrace of crowdsourced security testing has happened because it is proven to work better than traditional security testing methods and addresses the ever-growing talent gap within organizations,” said Synack CTO and co-founder Mark Kuhr.

The report found security testing is becoming part of an organization’s normal routine, rather than a once-a-year check of the box focused only on compliance. According to the report, 44% of the organizations and institutions surveyed perform security tests on a monthly or weekly basis, suggesting that they are moving toward a continuous model, which is further enabled by crowdsourced solutions.

The report also revealed that some 63% of organizations commonly use external vendors to identify and reduce vulnerabilities. However, 52% experience unwanted cost and complexity due to overlap in functionality from using multiple security vendors. Those two data points demonstrate that simplification provided by leveraging a single security testing platform could deliver savings. Synack claims crowdsourced security testing solutions provide 147% higher ROI than a typical pen test and can decrease the burden of testing on organizations by reducing the signal-noise ratio.

“This shift toward continuous crowdsourced security testing will allow organizations and institutions to have the best of both worlds by procuring technology that offers efficient and effective results while fulfilling best practice standards such as NIST 800-53 to meet compliance objectives,” said Kuhr.

“Although we are seeing a move toward a 24/7, 365 security culture at organizations in a wide variety of industries and geographies, there is still ample room for improvement,” said Aisling MacRunnels, Synack’s CMO. “Our survey found that on average, most security tests are lasting just 20 hours. As the number of cyber incidents continues to increase, it will be imperative for decision-makers to implement security testing solutions on a continuous basis with 1500-2000 hours of testing a year.”

Those increased testing requirements will ultimately become the foundation to build a DevSecOps culture in most any organization bound by compliance regulations.

— Frank Ohlhorst

December 17, 2019
DevOps: Get the Basics Right to Avoid Costly Mistakes

It is a truth of both agile and DevOps that speed is of the essence. This is a relative statement—some apps/portfolios/orgs envision speed completely differently than others—but if you are releasing more frequently than you were in the past, thanks to DevOps, that’s kind of the point.

Yet, we see a whole selection of things that fall by the wayside or are underserved. Security and testing are the easy/obvious ones. Considering the frequency with which we see “Unsecured Amazon storage bucket” (one announcement of this type spurred this blog), should we not see this folded into standard procedure or tools? Well, it is folded into standard tools for checking your cloud environment—I’ve used a couple of them and seen this warning come up. So shouldn’t organizations be using these tools more?

One thing about speed: It tends to cut corners. And cut corners lead to lapses. You can be a blameless environment that doesn’t punish people for mistakes, but for an organization, a mistake such as exposing hundreds of thousands of users will be punished from the outside, from regulatory agencies and the market in general. They’re not mistakes we should be making, and yet it still happens.

Another one is rollback versus roll forward. Most DevOps shops focus on the ability to fix an issue and plow forward. This works really well, 90+% of the time, and fails spectacularly sometimes. While it is an added step with some slowing of process, being able to roll back changes is important. And more than, “Well, theoretically, Git will allow us to go back to the last marked release …” because there is far more to an application architecture than just the source stored in a repository.

In short, no matter how fast things are going, have a plan for when things go wrong. Because they inevitably will. And take the little bit of extra time for preventatives such as warning someone other than the creator about buckets with no security.

“But there isn’t time …” is the common refrain to blogs such as this one. I get it. The increase in delivery only creates an increased appetite for delivery. But is there time to respond to disaster, should the worst happen? And I’d argue that it must be IT that plans for disasters. When someone gets fired because there was a security breach or a total systems failure, it is rarely an app owner. That puts the responsibility to make certain one doesn’t happen squarely on IT.

We’re delivering faster, offering increased functionality to users, moving forward on every front. You all are out there rocking it daily. Don’t risk all of that being ignored because you failed to take care of basic issues. Check out the tools to help out; feature flags and cloud security scanners both spring to mind with regard to my examples above. The tools are out there, you just have to work them into your process.

— Don Macvittie

November 27, 2019
How Combining DevOps and Agile Can Ease Black Friday Pressure

Every year, seasonal peaks such as Black Friday and Cyber Monday bring a higher volume and faster pace of work, as well as a considerable amount of pressure. This comes with a number of challenges, including managing traffic influx, ensuring top-notch digital experience, rebuilding catalog infrastructure and carrying out load and performance testing.

Development teams need to navigate increasingly complex tasks in time spans that are shorter than usual. That’s where Agile comes in: With its fast-fail nature, Agile fills the gaps between limited resources and market needs. By prioritizing self-organizing teams and robust feedback, its flexibility allows teams to rapidly refocus as business requirements inevitably shift.

DevOps, on the other hand, offers a more systematic approach. Despite its various overlaps with Agile, its signature benefit is its heavy reliance on the collaboration between development and operations throughout the entire product lifecycle. With continuous testing and delivery, DevOps ensures the delivered product is fully in line with customers’ needs.

Both approaches offer benefits to teams looking to navigate the complexities of the holiday season. Research by Cutter Consortium revealed that combining DevOps and Agile can lead to the reduction of the time needed to get a product to market by 20-40% and to significant cost reductions as well.

Why should teams leverage the marriage of DevOps and Agile to relieve the pressure of the holiday shopping season?

Automation as the Centerpiece

The last quarter of the year is traditionally seen as a trial that often stretches organizations to their full capacity. However, if organizations are still using obsolete manual processes, standards will slip. Exposing high-availability systems to human error during seasonal peaks that bring ten-fold higher traffic than normal may have dire consequences for a business. Automation, on the other hand, ensures that processes are less error-prone and vulnerable to human errors.

DevOps puts emphasis on automation. Not only does it focus on maximum efficiency when deploying software, but it also advocates for close process documentation. Automation facilitates optimal knowledge transfer and frees production teams from time-consuming manual tasks, allowing them to become faster and more adaptable.

It’s common that organizations claim that Agile and SCRUM simply don’t work for them. However, this is mainly because they haven’t achieved advanced enough automation levels or outsourced enough tasks to be fully flexible. But with automation, they can embrace it more effectively–as DevOps aims for the simplification of the entire process, its focus on automation establishes solid foundations for efficient Agile. This means organizations cut down the time to market and are more equipped to face the challenges of high season.

High Flexibility for a Better Product

Seasonal peaks such as Black Friday and Cyber Monday are always bound to agility. The revenue potential of an organization depends largely on the flexibility of the team and the processes and systems that, if maintained effectively, can add significant value.

Agile teams usually work in two-week grinds, and each of these sprints should result in certain features. However, in order to meet the business goals, these features must be usable. Without DevOps, it would be difficult to deliver something that brings incremental value. This is, for example, because agile teams often disregard automatic testing. But incorporating this DevOps principle ensures that the process is always moving in the right direction.

Likewise, if agile teams pay close attention to collaboration with customers, product management, developers and other parties, as DevOps suggests, they can develop a better product that has undergone review from various parties. That’s because DevOps can extend agile principles beyond the code to the entire delivered service.

The two approaches fit great together. Agile enables teams to produce minimum viable software and its features in a swift cycle, while DevOps ensures that the delivered product is of a higher quality. Such a complementary relationship wouldn’t be possible with the waterfall scenario where cycles last months or even years. While DevOps encourages integrational behavior, Agile relies on quick evaluation and incentives, so they come together in flexible solutions. This is fundamental throughout the high season, where priorities often shift fast and the needs of customers become more urgent than ever.

Close Oversight to Avoid Failure

As teams face increased pressure during Black Friday and Cyber Monday, errors become more likely. Deploying Agile together with DevOps guarantees there is a robust architecture that’s able to prevent failures.

DevOps practices allow agile teams to respond faster–not only to business requirements but also to any other problems that arise, too. When combined with the best practices of modularity and microservices, failures can often be isolated to a single system. Such a system can be fixed, replaced or completely removed with ease.

Organizations are increasingly aware of the importance of preventative analytics. For example, Slack integrations throughout the DevOps cycle can go a long way for early diagnostics. Agile teams incorporating DevOps can leverage continuous testing and monitoring that bring both constant progress and quality assurance.

Companies such as Etsy, a global handcraft and vintage marketplace, saw a lower occurrence of errors and disruptions after exchanging the waterfall model for a more agile approach. The organization relied on DevOps structures to deploy a fully automated pipeline and assured that continuous delivery practices secured a higher number of daily deployments–with fewer errors at the same time.

High Levels of Synergy

As mentioned earlier, DevOps has many convergence points with Agile, which is why they form such powerful partners with little chance of clashing. One of the fruits of their synergy has crystallized in the form of Infrastructure as Code (IaC).

IaC in a modular system, as promoted by DevOps, brings organizations remarkable benefits, as significant changes can be rolled out across the entire network typology with a single code change in minutes. In the context of feature requirement (or a failure), such velocity is instrumental to leveraging seasonality. This way, developers can alter entire environment configurations, regardless of the initial stage, and thus avoid tedious rebuilding.

Teams looking to optimize their performance shouldn’t be deciding between Agile or DevOps. In fact, organizations will find that their powerful combination can equip them much better for the seasonal peaks and help them deliver greater results than ever.

— Ain TohVri

November 22, 2019
An Embarrassment of Riches

History says people rarely appreciate what they have in the heat of the moment. Our highly connected and high-speed world is no exception to this rule. The things that frustrate us are in our faces, while the things that make nearly everything better/safer/faster are taken for granted.

That is every bit as true in IT as it is in life. We expect our deploys and releases to go easily, because life is far easier in that regard than it was even 10 years ago. We get frustrated when things don’t work out, because they so often do.

The one area Agile has addressed is that most shops don’t beat the person responsible for an issue until they leave. That’s not to say no one is judgmental, it just isn’t official policy to brow-beat even stupid mistakes. The goal is to get better, not to bash the person responsible for the mistake. Most of the time this is a downright positive change. Particularly since, in complex systems, it is often not one individual’s error, but many.

Before Agile, I rushed out a fix to a piece of software used by several large banks. They needed the fix, and I was most qualified to do it. I used the file handle for the printer to open a printer, and wrote to it. All went well in test and we shipped it out. The results were catastrophic corruption of one set of databases for several large banks.

Unknown to me, someone had re-used the printer file handle if certain conditions were met, and opened it on the database. It being reserved for printers, that never occurred to me, and I simple reopened it and used it. The strange conditions that pointed it at the database were never encountered in test, and I was responsible for some serious damage to our reputation and the banks in question’s confidence in our software.

Thankfully, our development team was already on “do it fast, don’t point fingers,” so it was mentioned that better testing could have been done, and we implemented plans to do just that, using scrubbed customer data. And the root cause–using a reserved file handle for access to something else–was fixed. My own angst as having created the mess made me sit with operations while they rebuilt the destroyed databases one at a time, using some astounding Unix command line wizardry. In the end, the software and the team were better off for the experience. And I got an early lesson in not trusting that code would behave as-expected.

The point being, bashing me for a mistake that put us all on high-stress because our biggest customers were rightfully angry would not have solved the problem. Letting me work through, identify root causes with the test team and get things straight worked better.

We’re facing a similar hill in DevOps today. Do you test in production? How much do you test in production? What if you have similar totally unforeseen issues crop up?

The answer is you must test in production. Inevitably, there will be errors in production, it is far better to find them early and fix them than to test in production because the app is live and there were things you couldn’t test outside of production. Either way, you’re testing in production, the question is how much control do you have.

This is one of the strong suits of DevOps. Using things such as feature flags, monitoring and AIOps, you can spin up a small percentage of production servers with changes. Or deploy parallel servers in production for low-server-count apps, then just stream a few customers to them to test out new changes. Yes, those customers might have a terrible experience if there is some unforeseen issue, but better a few customers than all of your customers if you rolled out without testing. For some industries, building a list of people willing to be used to test new features like this can be a marketing ploy.

Our frustration at things going wrong will still be there, but the joy of catching those problems before major catastrophe hits our production servers should be there, too. Not long ago, you rolled it out to everyone and dealt with the consequences. Crashes were big and even more frustrating. Better to have a few customers impacted and the ability to fix issues before it’s an emergency.

I’ve said it before, we work in astounding times with giant leaps forward in responsiveness. Take advantage of them. And take time away from making and running great software to appreciate them, if only for a moment.

Then add more features and fix more bugs. We are in the heat of the moment after all.

— Don Macvittie

October 25, 2019
Quality Engineering Has DevOps and Agile in the Driving Seat
As opposed to the traditional software development lifecycle (aka waterfall), today’s Agile and DevOps-based software development process is more outcome-oriented. The unrelenting pace of the changing market landscape has made the hybrid, Agile plus DevOps way of software development absolutely critical in addressing customer demands and staying competitive.

The focus on Agile and DevOps is necessary due to the high failure rates of traditional software development methodologies. These failure rates are mainly attributed to the glitch-infested, low-quality applications churned out by following legacy methodologies.

The failure rates had left many companies to bite the dust and brought the key role played by quality in ensuring customer satisfaction and ROI for the business into sharp focus. Also, the IT landscape is witnessing developments such as mergers and acquisitions, increased focus on risk and compliance, data and analytics, the fast rollout of apps and mobile commerce, among others. These have necessitated the software development process to become increasingly agile, streamlined, collaborative and flexible. The reshaping of customer expectations is letting organizations to go beyond shift-left testing or DevOps testing by transforming the QA process into one driven by quality engineering.

What Is Quality Engineering?

To meet the growing demand for quality software applications in double quick time, a mere tweaking of the software development process is not enough. What is needed is the adoption of software quality engineering process comprising optimal quality assurance, predictive analytics and monitoring of QA elements to reduce glitches to negligible levels. The process would involve a continuous cycle of feedback and quality improvement based on the same. The quality engineering process offers maximum test coverage in the shift-left scheme of things and ensures outcomes like functionality, security, accessibility, usability, performance and reliability of the software application. It complements Agile and DevOps methodologies and ensures their outcomes to remain consistent with the desired business objectives. Quality engineering, instead of identifying the inherent glitches in the SDLC, focuses more on preventing them altogether.

Shift Left and Strengthen Right

Quality engineering services cover the entire spectrum of the SDLC thereby yielding the maximum test coverage and delivering the best quality product. With DevOps testing shifting left, the quality determinants are incorporated right into the product build during the development phase. At the same time, DevOps-based QA focuses on the shift-right approach to ensure the last stage of the SDLC i.e., delivery goes on unhindered and customer feedback is taken in right way and worked upon. The ultimate aim of both shift-left and right is to create and deliver a glitch-free product that meets the requirements of the end-users. Here, since end-users are the ones who ultimately assess quality of a software product based on parameters such as usability, functionality and performance, among others, the feedback mechanism should be responsive enough to understand the issues faced by the end-users and remedy them at the earliest.

Quality Engineering as an Aid

Quality engineering (QE) helps to bridge the gap between development and deployment processes, which can arise due to the lack of agility. It harps on the successful strategy of “test early, test often,” to pre-empt challenges that businesses face when testing a software product. Quality engineering ensures the quality of a software application throughout the SDLC–right from the designing stage to its final delivery. QE can be incorporated into the development process by using methods such as Behavior-Driven Development (BDD), Test-Driven Development (TDD) and Acceptance Test-Driven Development (ATDD) respectively.

Let’s find out what these methods are all about:
- BDD: In this software development method, the behavior of both the software and business outcomes are taken into consideration. Here, the right sets of tests are automated, leading to an increased collaboration among developers, testers and other business stakeholders.
- TDD: In this software development process, the QA team writes unit level tests before the development stage. This results in getting an early feedback and helps the development team to refactor its requisites.
- ATDD: This software development process focuses on writing an acceptance test even before the development phase. This helps the software to meet the acceptance criteria beforehand.
Quality Engineering and DevOps

QE, being an end-to-end testing methodology, can offer optimum solutions to businesses struggling with their legacy IT infrastructure. The solutions in terms of continuous testing and integration as mandated by DevOps, can be arrived at by integrating the QA process with the DevOps pipeline. This results in executing processes such as build, test, deploy and deliver in a seamless manner. QE complements DevOps and Agile by detecting glitches right at the beginning of the development process.

Moreover, QE’s focus on end-to-end testing helps the product to be developed and tested simultaneously. This approach adds teeth to the DevOps’s requirement for continuous integration (CI) and continuous delivery (CD). No wonder, the successful implementation of quality engineering is underpinned on fulfilling the requirements of DevOps and Agile. It further consolidates the benefits achieved from implementing DevOps testing services and Agile testing services.

QE riding on DevOps and Agile can help businesses to scale up their operations without investing much resources and time. By implementing DevOps test automation and Agile test automation using a test automation software such as Selenium, Robitium etc., businesses can boost their SDLC. QE can help businesses to develop and deploy glitch-free software speedily and deliver enhanced customer experience.

Conclusion

The fast-changing competitive business landscape of today requires organizations to streamline their operations, increase productivity and fast forward the delivery of glitch-free software applications. To achieve these objectives, they need to make quality engineering as part of their development and testing cycles. However, QE ends up complementing the Agile and DevOps approach by achieving outcomes such as CI and CD. Furthermore, it leads businesses to get high ROI, better productivity, reduced cost of operations and enhanced customer experience.

— Akshaya Choudhary
October 15, 2019
Why COBOL Still Matters After 60 Years
In the world of DevOps, the Agile Manifesto and countless other application delivery frameworks, one has to wonder how an anachronism such as the programming language COBOL (common business-oriented language) has managed to remain relevant. After all, COBOL has its roots back in the 1940s, and was built upon Rear Admiral Grace Hopper’s work on the FLOW-MATIC programming language (a text-based programming language). Hopper, who worked as a technical consultant on the FLOW-MATIC project, is sometimes referred to as the grandmother of COBOL.

Last century, COBOL quickly became one of the most used programming languages in the world and it is still quite popular, claiming more lines of code in active use today than any other programming language. It offered a huge advantage over the other programming languages of the era. One that can be summed up as portability. From the outset, COBOL was the first popular language designed to be operating system-agnostic. In other words, it could be run on numerous different systems with little change made to the source code. What’s more, as a text based language, COBOL used English words and phrases to make it easier to understand and also made it somewhat self-documenting.

While much of the programming world has moved onto JavaScript, Python, PHP and even C and C#, COBOL can not be ignored. It continues to evolve and remains relevant, even in the age of the cloud. Simply put, it still has some chops to it. Take for example:
- COBOL is a Language of Business: It is still used by the majority of major banks and insurers. The language can be found in widespread use across numerous other sectors, such as retail, healthcare, government and automotive. For most of those businesses, no other programming language has displaced COBOL and it remains as the back-office business language of choice.
- COBOL is Extremely Portable: From the outset, COBOL was designed to be operating system agnostic, meaning the same applications developed under it could run unchanged across many different platforms. That allows COBOL developers to focus on building applications, instead of worrying about the intricacies of operating systems. That fuels DevOps and agile by allowing developers to test and deploy across a wide range of supported platforms.
- COBOL Continues to Evolve: It supports and integrates with numerous platforms and works with operating environments such as Linux, mainframes, Windows and UNIX. What’s more, COBOL also integrates with Java, C#, Docker containers, mobile, .NET and JVM as well as Azure and AWS cloud environments. It can be used today to build cloud, containerized and managed code apps. And continues to evolve to meet the challenges of the future.
- COBOL is Easy to Learn and Understand: It was created with the objective of making it easier for programmers to work with computers and each other. That objective has translated into a language easy to learn and understand by using English phrases and commands. The readability aspects of COBOL make it self-documenting, along with an ease of use not found in other languages. What’s more, the language costs less to maintain and its readability means it is easier to maintain.
- COBOL is Future-Proof: It has continually evolved and now works with industry-standard IDEs, meaning programs can code with COBOL using familiar tools that support teams. COBOL developers are able to use the language alongside contemporaries, without having to forgo the latest IT tooling and processes.
While many in the DevOps world sell COBOL short, there are many reasons why the language remains popular today. It continues to meet the needs of business and embraces many of the changes the cloud and new techniques can throw at it. COBOL is even now embracing APIs, micro services, the cloud and distributed platforms, making it a worthwhile tool for business today.

— Frank Ohlhorst
September 11, 2019