Working Through Library Updates

• Library updates can be the hardest to make because a library becomes part of the application code. Because you import it directly into the application, some changes are hard to hide from view. In addition, some changes can cause odd problems to surface—bugs that have always been in the library, but never showed up because the application allocated memory or other resources in a different manner. The update may not even appear in the application after including the new library because the calls may have a slightly different name. These issues are all common to any sort of library update you wish to make. The following sections divide libraries into those that you incorporate from a third-party source and those that you develop on your own.

Working Through API and Microservice Updates

APIs and microservices both suffer from the same problem—they work as black boxes for the most part. It’s possible to sneak an update in without anyone knowing. Some vendors have actually done this in the past, and it isn’t unheard of when working with in-house code either. The black box issue can cause all sorts of problems when the API or microservice fails to work as expected. Tracking down the culprit can be difficult. With this in mind, it’s essential to ensure that the development team fully documents every change to the internal workings of an API or microservice call and that the outputs remain the same for a given input. The following sections discuss the differences between third-party and in-house updates.

Developing in-house API and microservice updates

Always perform static testing as a first measure of in-house updates. During the process, you want to verify that the documentation and the code changes match completely. A significant problem with updates is that the API or microservice development team thinks that an update works one way when it actually works another. It’s also a good idea to match documented updates against trouble tickets to ensure that the fixes address the issues described in the trouble tickets. This visual checking process might seem time consuming, but performing it usually makes subsequent testing far easier and reduces the probability of a security issue sneaking into the code accidentally significantly less. The black box nature of API and microservice code makes the static check even more important than it is for libraries.

Your in-house code will also benefit from the same sorts of checks you perform on third-party code (see “Dealing with third-party API and microservice updates” for details). However, you can now perform these checks with the code in hand to better understand why certain checks fail.

A particularly tricky issue when working with microservice updates is that many organizations now rely on a microservices API to make the various microservices look like a custom API. The use of a microservices API reduces the programming burden on developers and ensures that every platform has the required resources using protocols available to that platform. Figure 14-1 shows a typical microservices API setup.

Figure 14-1. When using a microservices API, test the API as well

It’s essential to test the various microservices directly to ensure the update hasn’t changed the way in which the microservice works natively. However, you must also test the microservice API to ensure that the API still responds correctly to all the platform types that the application supports. Otherwise, you can’t be certain that the microservice API will continue to provide correct results in a secure and reliable manner.

Accepting Automatic Updates

Some vendors now make it as hard as possible to ignore automatic updates. An automatic update is one that a vendor pushes to a client in some way. In some cases, the vendor simply changes the software at the server so you end up using the update automatically. These are the main reasons vendors like automatic updates:

• Fewer security or reliability issues due to using an outdated version

• Reduced support costs

• Smaller staffing requirements

• Improved ROI

Of course, the question isn’t one of whether automatic updates are good for the vendor, but whether they’re good for your organization. In many cases, using automatic updates proves problematic because the organization isn’t prepared for the update and breaking changes usually create support issues. The most severe cases result in data loss or security breaches, which run counter to making an update in the first place.

Most organizations try to avoid automatic updates when possible in order to reduce the potential for unexpected side effects. When a third-party vendor insists on automatic updates and you have no alternative for third-party software, then you really do need to have someone tracking the third-party software to determine when an automatic update will appear. Testing the update immediately can help you avoid problems with breaking updates and potentially improve the ability of your organization to react to sudden changes as well.

Creating a Supported Language List

Not every application supports every world language. Trying to make this happen would be a logistics nightmare and it isn’t necessary because not everyone will actually want to use your application. However, you may find that you need to support more than just one language as the application becomes more popular. Modern server software generally makes it possible to track the locations that access your application. The location itself may not provide everything needed. For example, it may surprise you to know that Romania has a number of official languages:

• Romanian

• Croatian

• German

• Hungarian

• Romani

• Russian

• Serbian

• Slovak

• Ukrainian

However, these are just the official languages. Your application user might actually speak a different language, such as Italian. It isn’t possible to know precisely which language to support based solely on location. The point is that if you suddenly find that your application is receiving lots of requests from Romania, you already know that the user is not likely to speak English natively (or perhaps at all). If your application only supports English, then you might find the user is confused, makes mistakes, and potentially causes both security and reliability problems.

Using location does provide you with a good starting point, but you need to obtain language statistics in some other way. About the only effective means to ensure you get good data is to provide feedback forms or conduct user surveys. As you accumulate statistics about application use, you see patterns emerge and can start deciding which languages to support. Creating a list of supported languages is important because you need to know which languages you can actually afford as part of an update and you want to be sure you target the most popular languages first.

Obtaining Reliable Language Specialists

If you choose to perform a language-specific update of your application, you can only ensure that it works reliably and securely when the update looks as if you originally wrote it in the target language. Everyone has worked with instructions or other written communication that someone originally wrote in another language and then translated to whatever language you speak. When the translator exercises less than the usual skill, the results are often hilarious. The actual meaning behind the various bits of information becomes lost and no one can take the information seriously. However, the security issues that this kind of miscommunication causes are no laughing matter.

However, even a great translator will do a less than perfect job if you don’t provide the right environment in which to perform the translation. The following steps provide insights into the techniques you can use to create a better application translation and ensure users can actually follow your prompts as a result:

1. Place all hardcoded strings in the application in a database of some type. Identify each string by its location within the application.

2. Replace each hardcoded string with a placeholder control that you fill with the correct language string when the page loads.

3. Create a separate database file for each language and ensure the database name reflects the language content.

4. Fill each language database with the translated strings provided by the translator. Use precisely the same identifiers for each of the strings so that the identifier always matches the screen prompt.

5. Add code to the application to perform the task of filling the controls with the correct prompts from the database.

6. Test the application initially with the original language to ensure that the prompts work as intended.

Verifying the Language-Specific Prompts Work with the Application

Simply translating the prompts isn’t enough in many cases. You need to rely on your language specialist to ensure that every prompt on every screen reflects how people who speak the language natively expect to see the prompts. For example, some languages read from left to right, while others read right to left. The orientation of the prompts is important, as is the formatting. You may need to provide application hints and formatting to ensure that people using the application can actually interpret the prompts correctly.

Ensuring Data Appears in the Correct Format

Different areas of the world format data in different ways. Some countries use a comma, instead of a period, for the decimal place. These same countries might use a period, in place of a comma, for the thousands place indicator. Imagine what would happen if a user changed values based on the wrong formatting in this situation. A user could enter values that could cause the application to misbehave, crash, or simply do something odd. The result could be a security breach or an opening that a hacker needs to create a security breach. Many security issues come out of seemingly silly errors that a hacker exploits to gain the small advantage that leads to a big payoff.

The presentation of data in the right form ensures there are no misunderstandings. Creating a potential security issue simply because of a mix-up between commas and periods seems like a problem that you can easily solve, but sometimes proves absurdly difficult. You can find examples of thousands indicators and decimals points by language at http://docs.oracle.com/cd/E19455-01/806-0169/overview-9/index.html. The graphic guide at http://www.statisticalconsultants.co.nz/blog/how-the-world-separates-its-decimals.html is also interesting.

Defining the Special Requirements for Language Support Testing

Testing your application becomes a lot harder when you start adding multiple languages. Unless you plan to keep those language specialists around for the life of the application, you need some other means to verify that updates aren’t causing language support problems. Proper planning, change documentation, and verification in the original language are your best starting points. Whenever you create a change to the application that affects a prompt in the original language, you must consider changing the prompts in all of the other supported languages as well. To make this process as easy as possible, use these suggestions:

Plan

Make sure you check each change carefully. Sometimes a designer will try to tweak prompts when they don’t really require any change. Keeping the number of changes small will reduce costs, ensure the application remains reliable, and help improve security by reducing the potential for miscues.

Document

Every change to every prompt in the original language must also appear in every other language your application supports. A security and reliability issue starts when the language editions get out of sync. It’s essential that this part of the update process runs smoothly and without error or you’ll find yourself hiring that language specialist again to clean up the mess.

Verify

Ensuring that every change occurs in every location is hard because you probably don’t have staff that speaks the language you support. A good way to verify the language update is to use screenshots. Compare the original screen to the updated screen to verify that the prompt changes really did take place. The only problem with this approach is that you can’t be sure that prompt change is completely correct.

Avoiding Emergencies When Possible

Everyone experiences an emergency at some point in the application support process. It just goes with the territory. However, you can avoid most emergencies by planning for them before they happen. Here are some issues you need to consider as part of avoiding emergencies:

• Perform full testing of each update and upgrade before deployment.

• Deploy updates and upgrades only when system load and availability supports it.

• Avoid deploying updates and upgrades when staffing levels are low or key personnel are absent.

• Ensure the application has access to all required resources from multiple sources if possible.

• Plan for overcapacity situations and ensure you have adequate additional capacity available to meet surge requirements.

• Assume a hacker is going to attack at the worst possible time and plan for the attack (as much as possible) in advance.

• Test system security and reliability regularly.

Creating a Fast Response Team

Your organization needs a fast response team—a group of individuals that are on call to handle emergencies. It doesn’t have to be the same group of individuals all the time—everyone needs a break—but you should have an emergency response team available at all times, especially those times when hackers love to attack (such as weekends). An emergency response team must contain all of the individuals that an application requires for any sort of update. If you require a DBA to make an update normally, then you need a DBA on your emergency response team. The team should train together specifically on handling emergencies to ensure they’re ready to go when the emergency occurs.

Performing Simplified Testing

Depending on the nature of the emergency, you may have to release the update with a minimum of testing. As a minimum, you must test the code that the update directly affects and possibly the surrounding code as well. When a hacker is breaking down your door, you might not have time to test every part of the code as normally required. It’s important to remember that the update you didn’t release might have kept the hacker at bay. The issue comes down to one of balancing risk—the emergency on one side and the potential for creating a considerably worse problem on the other.

Creating a Permanent Update Schedule

Always treat emergency updates as temporary. You have no way of knowing how rushed the fast response team became while trying to get the update out. The team could have made all sorts of errors during the process. Even if the update works, you can’t leave the emergency update in place without further scrutiny. Leaving the emergency update in place opens security and reliability holes that you might not know are there and could cause considerable problems for you in the future.

As part of the permanent update process, make sure you perform static testing of the update to verify that the fast response team reacted properly and provided a good fix for the problem. Make sure you schedule the permanent update as quickly as possible to ensure you fix any additional problems before someone takes advantage of them. The new update should rely on all the usual testing procedures and follow whatever plan you have adopted for permanent updates.