Maintaining software, applications and web platforms has business benefits in the first place. It may seem that once you’ve released a useful and popular product, you’ve already achieved success. Practice shows that this is only the beginning of the path.
The world of technology is constantly growing and changing, offering new opportunities for developers to meet the growing needs of users. What was important yesterday will not matter tomorrow. To quickly adapt to these changes, you need to maintain your product up to date.
In addition to fixing bugs, you also can increase flexibility, improve usability, enhance the efficiency of your product. This will surely lead to increasing loyalty and customer satisfaction, and, as a result, boosting revenue.
Computools takes a comprehensive approach to the issue of software product maintenance and this is how it happens.
It all starts with the development of a CI/CD plan at the architecture design phase. A docker-based infrastructure is used to keep the identical workflow of the system in different environments. Engineers apply Docker or Docker-compose for work within one server; Kubernetes for multi-server environment deployment; Docker swarm and stack could be an alternative for multi-server environment deployment.
Then the team moves on to the development of configuration and deployment of the next environment types:
1. Dev (development) environment is used in the development process and for testing a feature/branch. Low price is an important requirement even to the detriment of a number of non-functional requirements including stability and uptime. So, production compliance can be incomplete. Single nodes can be raised instead of clusters. The vendor of server resources should not be the same as on production in a common case.
2. QA environment is used for regression testing of the build or release candidate. Production compliance must be higher. Clusters must be configured in the minimum configuration. By default, the server resource vendor must be the same as on production.
3. Staging/demo environment is used for demonstrating the project to clients and their partners. The staging/demo environment is a copy of the production environment. At high prices of the production environment allows using the equivalent which is close, but doesn’t correspond to all production requirements. This question is negotiated with the client. It can be combined with a QA server in the early stages, but it is not recommended if the client also holds demonstrations. Clusters must be raised in the minimum configuration. By default, the server resource vendor must match production.
4. Production environment is used by end-users and corresponds to non-functional project requirements and maintains stable work of the necessary software. By default, the capacities of reliable vendors such as Google Cloud, AWS, Microsoft Azure are chosen.
Looking for a skilled development team to maintain and upgrade your digital product?Contact us →
During work on the project, engineers use different types of recourses. For example, infrastructure consists of tools that are used for project development. Basically, the solutions are rented or deployed in the corporate network: GitHub, GitLab, Bitbucket – are version control systems (based on git) and UI for these systems; Jira is used as a task or a bug tracker; Confluence – a specification management system and knowledge base; Jenkins – a continuous integration (CI) system; SonarQube – a code analyzer; Build Server to build the builds based on docker and run of all test types; plus domain-specific tools.
Choosing an application or service, many factors are taken into account, such as developing a system, ready-made solutions, internal DNS, platforms to work with content, load balancers, clusters, domain-specific tools. Special attention is paid to selecting storages, picking the most proper according to project requirements: SQL database (PostgreSQL, MySQL, Oracle, MSSQL, etc.); document-oriented database (MongoDB, CouchDB, Elasticsearch like a search engine, etc.), column-based (HBase, Cassandra, etc.), other storages, queue and cashes (RabbitMQ, Redis, Memcashed, graph database, etc.) If necessary, the team also develops and configure additional systems necessary for horizontal scaling.
Computools’s experts encourage to use Vendor’s API from AWS or Google cloud that includes CDN. CDN is recommended to use for static files which are critical to loading speed. Configuration of vendor’s resources consists of internal client’s servers for remote access (ssh, rdp, other types of remote connection), VPS for access to the control panel (AWS, Google Cloud, Digital Ocean, Microsoft Azure, etc.), Vendors’ API (AWS, Google Cloud, Microsoft Azure, Heroku, etc.).
Next, the team proceeds to deployment and configuration of internal infrastructure by deploying environments. Engineers start with the configuration of physical or virtual machines, install and/or configure operating systems. The CI/CD system configuration includes CI and version control system integration and CI and continuous testing configuration.
Their next step is a configuration of required systems and dependencies, implementation of horizontal scaling schemes and integration with Kubernetes (internal network and DNS configuration; load balancers configuration and testing; development and testing of solutions for horizontal scaling of subsystems. To ensure the safety of project data, software security configuration is conducted according to the following criteria: access restriction, firewalls, work with ports, connection restrictions from outside the internal network, DDoS protection, data encryption, configuration of vendors’ systems.
Last but not least is the configuration of log analysis systems, primary stack Elasticsearch, Logstash, and Kibana.
Then the team proceeds to environment status monitoring; if necessary new environments can be deployed. Load and security analysis are conducted according to the previously approved schedule. Deployment of additional capacity for carrying out the types of automatic testing is not included in the mandatory testing when making a build.
Basically, this is the technical part of the work of the whole ecosystem aimed at providing you with complete and periodic product maintenance, testing, and monitoring paired with ongoing improvements.
If you would like to receive more information or to consult on the terms of cooperation for maintenance and improvements of your product, feel free to contact the specialist by email at email@example.com or through the form below.