Geolocation Service Success: CI/CD and Full QA

Provided services

Backend Development, CI/CD Implementation & Modernization. DevOps Services, Software Integration Services

Client

Our client is a large telecom solutions provider with his ecosystem developed for any needs of end customers.

Product

One of the client’s ecosystem components is a set of mobile devices and applications on these devices.

At a certain moment, it became necessary to determine the location of the device using the application running on it.

The service provides the possibility to track the current location of a digital device for searching the movement of an object in space and recording along the route and over time.

The client’s customers use the service to control and optimize their business processes. The benefit lies in the fact that the application is always aware of the device location and, depending on the tasks, provides the most relevant information upon request or as an offer.

Challenge

The component being developed is at the top of the client’s product line. It was important to make it stable within a single iteration. The development pipeline for other components was tied to it and we did not have the opportunity to make it unstable. It is a very complex component (lots of settings). However, it was necessary to ensure the reliability of this component in various conditions. The flexibility and scalability of the solution also had to be guaranteed.

The customer wanted to quickly deliver a stable component, not in beta, but actually already stable and working. Even though we had to do auto-testing and set up CI/CD, we managed to complete the task. The component became the basis for the customer’s solution.

Solution

Our team developed our own Mule REST service called GetAdressByIP, which can use third-party services to determine the geolocation. In cases when the IP address of the device, on which the application is deployed, is not available, X-Forwarded-For header HTTP/HTTPS is used to determine its IP address.

Processes Improvement

One of the customer’s requirements was to minimize labor costs during deployment and testing. Developers should have focused as much as possible on software product development. To fulfill this requirement, the Continuous Integration, Continuous Delivery (CI/CD) process based on Jenkins was implemented.

Five processes were automated using Jenkins:

Build. Jenkins starts the project build after every commit.
Publication. It extends the product version, creates a new tag in the code repository, and publishes the created zip archive in the Sonatype Nexus repository.
Changes undo. If errors occur during publication, this process helps undo all changes.
Release. It gets the required version of the GetAdressByIP service, downloads it from Nexus, and deploys it on the Mule applications server.
Building and deployment are started manually and do everything the processes described above do, except release creation. It is intended for the developer, who wants to test how the application works on the Mule server.

As a result, this significantly reduced the developers’ time they spent on building, testing, and deploying new versions manually.

The Data-Driven Testing approach was applied during the testing phase. The performed integration tests covered a wide range of cases.

Technological Overview

The GetAdressByIP operation algorithm is as follows:

GetAdressByIP accepts a location request. To restrict access to the application by third parties, the REST interface accepts the API_key in the request parameters. API_key is a unique identifier used to authenticate the calling system.
After successful authorization the IP address is extracted from the HTTP(S) header of the request, and to identify the origin of the user’s IP address, the X-Forwarded-For header, for example, can be used.
After that, a request is created and sent to a third-party API to obtain the user’s location under the specified configuration. The configuration specifies which third-party service should be used to determine the geolocation.
The received response is sent back to GetAdressByIP, where it is processed and sent to the client application from which the original request was sent.

Data between the client and the server is exchanged in JSON format. The operation diagram of the application is shown in Figure 1.

Figure 1. Diagram of interaction of the implemented application with client applications and an external address determination service

Result

It was possible to make the component stable and it formed the basis of the client’s solution.

The customer wanted to quickly deliver a stable component, not in beta, but actually already stable and working. Although we did autotesting and set up CI/CD. This is an example of a “quickly-effectively-to-life” scheme.

Many of our best practices used for Mule solutions implementation during this project served as the basis for creating the article “Best Practices for Using Mule ESB“.