Every element of your software delivery chain is important. You know that.
But, as is the case with almost anything that involves human beings, or machines, or both, there are times when it is all too easy to assume that the most visible elements of a system or process are also the most important. And it is also all too easy to assume that the less visible elements of the process are not very important at all.
In a typical DevOps continuous delivery chain, production is usually highly visible. It, after all, is where the wheel hits the road, the point at which your application or service meets your customers, and where any functional or performance issues are likely to not only become apparent, but also result in problems which require immediate remediation.
But the truth is that production is just the final stage of the delivery cycle. Without development and testing, there would be very little to deliver.
Consider the following scenario:
You have an excellent delivery chain (at least at the production end), and an existing application. It might be a legacy application which you intend to deploy in a cloud environment, or it might be an application developed outside of your operation (by outsourcing, for example).
Your production team can deliver the application, and maintain it at the level of infrastructure. But you have no development team, no test team, and thus no provisions for ongoing support at the level of code.
No application exists in a vacuum. Infrastructure consists of discrete elements (operating systems, support applications and services, APIs, runtime libraries, and the cloud itself), all of which can, and almost certainly will, change over time. This means that over time, the application's code will become less and less compatible with the infrastructure in which it must function.
Theoretically, of course, your production team could continue to maintain the application by continually tweaking the infrastructure to maintain the legacy conditions under which the application must operate. Eventually, however, this will add an increasing amount of functional overhead, which is likely to show up in such forms as slower application response, increased use of memory, storage, and other resources, more frequent and more pronounced application failures, and longer time to repair.
At some point, if there are no major revisions at the level of code, the application is likely to either become unworkable, or so visibly outdated that it loses a significant part of its market share.
This is the functional cost of having no development and no testing. But for any application operating in the highly competitive world of online software and services, or for virtually any website, this cost would be only a small part of the price you pay for neglecting ongoing development and testing.
In the real world, applications and websites need to do much, much more than simply remain functional. Your application needs to look fresh, it needs to be able to do at least a good selection of the latest tricks (even if they do not enhance your core functionality), and it needs to continually provide new services, and visible improvements in existing services. Otherwise, its market share will be continually eroded, even if it has no major problems at the functional level.
But if you are involved in the management of software production and delivery, you already know this. You know that you have to keep your code working, and you know that you have to keep your products, websites, and services fresh-looking and up-to-date. And you know that your development and test teams are absolutely indispensable to your operation.
It is easy, however, to take the development and testing environment itself for granted, to assume that your developers and testers are self-maintaining, and that the resources which they have available by default are sufficient. But environments and resources do make a difference, and sometimes a very great difference.
A great deal has been written about the organizational aspects of the development environment, of course, and the issues addressed by the major development management theories and schools of thought are important. But for now, let's just consider the question of tools and other functional resources that make up the development and testing environment.
Development and testing tools are not glamorous. They are generally not very flashy, and people who are not directly involved in their use are likely to see very little in them to get excited about. But if you are a software developer or a quality assurance technician, you will almost certainly be very aware of both the strong points and the deficiencies of the tools you use. This is true of both software and hardware, and infrastructure and specific applications.
● Are libraries and other resources fully and flexibly integrated into the development environment, and are all those resources up-to-date?
● Do the development tools which are available to you fit your particular style of working, or do you find that they frequently get in the way and slow you down?
● Does the development environment require you to move between multiple windows or use menu selections and dialog boxes to perform common, repetitive tasks, or can you easily automate such processes, and avoid the graphic user interface entirely?
● Has your development environment become a maze of patches and workarounds added incrementally over time as a way of keeping an increasingly obsolete set of tools functional for "just a little while longer"?
Developers are very resourceful, and they're generally very good at making the tools which are available work. If they know or suspect that if they request the latest development tools that they will not get a sympathetic hearing at the management level, they are likely to find ways of making the old tools work long past the time when those tools should've been replaced.
It is tempting to see this resourcefulness as a highly positive trait, and in many ways it is. But extending the life of obsolete or inadequate tools by means of workarounds can eventually result in both a reduction of quality, and increased development time.
Ultimately, if existing development tools become too outdated, patches and workarounds will no longer suffice, and it may become impossible for your developers to make use of the latest features, or, worse yet, to keep your software running in the face of changes to infrastructure, operating systems, and runtime libraries.
If, on the other hand, you keep your developers happy by supplying them with the new and updated tools which they require, and making sure that their working in an environment which supports their style of work, you are much more likely to see both a continued high level of productivity and a rapid turnaround.
The same is true of your test team, and the testing environment. If developers are all too often taken for granted, it is even easier to treat testing as an afterthought, or even to neglect it entirely. In order to provide adequate results, your software testing environment and the associated tools should accurately reflect the actual deployment environment.
This means that they must be kept up-to-date. If you are deploying software in virtualized environments in the cloud, your testing system should be automated, virtualized, and cloud-based. Unfortunately, if you do not give your testing process the attention it deserves, you may find yourself relying on an outdated system of testing (for example, one which is manual and hardware-based) simply by default.
And yes, platform-based tools make a difference as well. Alibaba Cloud's new Elastic GPU Service, for example, offers extremely fast, GPU-based computing, with powerful concurrent and floating-point capabilities, making it ideal for computation-intensive applications, including deep learning, scientific, engineering, and financial computing, and media rendering and encoding.
The advantages these capabilities offer to your development team (from design through implementation) are clear; they can mean the difference between being able to put in place all of the features which your application requires, or having to make do with low-performance workarounds.
But the Alibaba Cloud advantage is not simply confined to one or two features. It's there for your developers across the full range of Alibaba Cloud's products, starting with Alibaba Cloud Elastic Compute Service (ECS) itself, and including database, storage, Big Data, and multimedia services.
Don't take our word for it, though: try Alibaba Cloud's free trial offer (https://www.alibabacloud.com/campaign/free-trial#free-products, with $300.00 credit), gives you a chance to see for yourself what many of Alibaba Cloud's features and services can do for you.
source: https://pixabay.com/en/programming-responsive-html-css-1873854/
Bio
Michael Churchman
@mazorstorn Michael Churchman started as a scriptwriter, editor, and producer of the game industry, working on the prototype for the laser-disc game Dragon's Lair. He spent much of the 90s in the software industry. During that time he developed a semi-automated system for managing localization in over fifteen languages. For the past ten years, he has been involved in the analysis of software development processes and related engineering management issues.
Remote Configuration for Android using Alibaba Cloud Table Store
2,599 posts | 764 followers
FollowHaydenLiu - December 5, 2022
Alibaba Clouder - November 20, 2017
Alibaba Clouder - August 28, 2019
Alibaba Clouder - April 22, 2019
Alibaba Developer - March 31, 2020
Alibaba Cloud Community - May 6, 2024
2,599 posts | 764 followers
Follow
Mobile Testing
Provides comprehensive quality assurance for the release of your apps.
Learn More
Penetration Test
Penetration Test is a service that simulates full-scale, in-depth attacks to test your system security.
Learn MoreMore Posts by Alibaba Clouder
