There are many benefits of combining Long-term and Short-term support releases: being flexible and scalable while guaranteeing stability to our customers, minimizing support and development costs while ensuring the best quality of service.
But before the release of this first LTS version, the 2.7, we had to reconsider a number of things in our internal organization. This project made the Combodo teams take a step forward, and we will see in this article how we organized ourselves to meet the challenge.
How to build the first LTS version in the history of Combodo?
This project took a little over a year, mobilizing several teams within Combodo. A few figures summarize this year of development:
Faced with our ambitions, we revised our way of working as the project progressed.
The retrospectives carried out on the previous versions of iTop showed us the increase in requests over time. Given the size of the project, we decided to set up a weekly monitoring of the backlog: this allowed us to quickly identify any slippage and act accordingly to limit delays.
Like the whole world at the beginning of 2020, we suffered the COVID-19 pandemic and suddenly our whole organization had to be changed. We like to do pair programming and code reviews, and we discovered the pros and cons of remote work:
🤔 This work change undergone by the teams, added to the delay with respect to the initial planning, required flexibility in order to find the best way to operate.
So we looked for the right tools (chat and visio: finally Combodo adopted Rocket Chat) and agreed on how to use them, in order to guarantee a way of working validated by all.
In order to improve the application’s code quality, pair programming (or peer programming) has been generalized. There are several advantages to this practice:
This practice also has some drawbacks:
Nevertheless, for us, the benefits have largely outweighed these few drawbacks. This method was therefore definitely adopted.
We have also set up post-project code reviews. This is not necessarily an easy exercise.
As iTop is a complex application, it is difficult for the developers to know the whole code base, or simply to evaluate the impact of a change on the whole application. However, as the whole team has been working on this version at the same time, the emulation allowed to find connections between related topics (functional as well as technical).
This was the opportunity to start creating internal pull requests to facilitate reviews, and to better integrate features in the Git history. In iTop 2.7.0, 16 internal pull requests have been integrated!
Thanks to the development of iTop 2.7 release, PHPUnit tests, which were in their first stages of development at Combodo, have grown significantly since we went from a few dozen tests to several thousands!
Moreover, all tests have been automated using Jenkins and are launched at each commit for a part of them, and daily for the whole.
In addition to these PHPUnit tests (which essentially cover iTop’s core functions), GUI tests have been also performed using Behat and also executed daily.
This much larger range of testing made life much easier and gave confidence to the quality team in charge of our product validation.
Once this organization is in place, it must be sustained, and it is also necessary to anticipate the future and the technological evolutions which are part of the important challenges of an LTS.
Because the schedule of supported PHP versions is evolving rapidly, contradictory aspects must be reconciled:
That’s why we have chosen a range of versions from PHP 5.6 minimum to PHP 7.4 maximum.
The release of MySQL 8.0 also raised doubts about iTop’s performance since one of the major changes in this version was the removal of the query cache. We’ve considered that implementing a SQL query cache in iTop was out of scope, but we’ve made iTop compatible with this version anyway!
Thus, we had to work on several aspects:
As incompatibilities had been corrected, we’ve conducted performance tests which confirmed the very negative impact of the removal of the query cache.
As a result, a specific communication was made to warn our users about these performance issues with MySQL 8, and advise them to use an earlier version of the database server.
We then carried out an inventory, and for each library we checked if an update was required.
Having the file composer.json in our repository brings us efficiency thanks to the support of our development tool PHPStorm, and also guarantees that we do not miss important information thanks to the Dependabot integrated to GitHub.
We have also adapted our processes and added, before each major release, a new “foundations” phase including librairies control and their update.
We had to replace Silex librairy (out of support since June 2018) by Symfony. Cette nouvelle librairie a aussi un calendrier de support calqué sur PHP. Nous étions donc limité sur la version Symfony utilisable dans iTop 2.7.0.
Silex has therefore been replaced by Symfony 3 while foreseeing the transition to Symfony 4 and 5.
A large part of iTop’s code is made of APIs: indeed, the extension creators use a lot of our classes and methods! But if the Combodo development team needs to be able to restructure the iTop code from time to time, it is also essential to guarantee stability to these developers, and to simplify the migrations of the extensions.
So we worked on different projects :
Deprecated methods are flagged with phpdoc @deprecated tag, the iTop version and as much as possible an indication of the code to use instead. For each deprecation, a deletion ticket is entered and scheduled for one of the next iTop releases. Everything is documented in the migration logs (e.g. for iTop 2.7.0 in a chapter of What’s new, for iTop 3.0.0 in a dedicated page)
For example the documentation of the method \DBObject::DBInsertTracked has been modified for iTop 2.7.0:
/**
* @internal
*
* @deprecated 2.7.0 N°2361 simply use {@see DBObject::DBInsert()} instead, that will automatically create and persist a CMDBChange object.
* If you need to persist your own, call {@see CMDBObject::SetCurrentChange()} before.
*
* @param CMDBChange $oChange
*
* @return int|null
* @throws CoreException
*/
public function DBInsertTracked(CMDBChange $oChange)
And this method DBObject::DBInsertTracked has been removed in 3.0.0 (commit 80161b9).
Several of our customers have requested a security audit performed by an external agency for their own version of iTop and have pointed out some flaws.
We have decided a security audit performed on the beta version of 2.7.0 to identify and help fixing as many flaws as possible before the official release of iTop 3.0.0.
So that flaws are reported as quickly as possible and corrected as well as possible, we have also defined together and published our security policy on our GitHub repositories (e.g. on iTop).
Vulnerabilities are published 3 months after the release of the first version containing the fix to allow our users and customers to update their instances. The publication is done through GitHub security advisories and CVE.
The security audit and the reporting of vulnerabilities thanks to the implemented policy have allowed to correct 30 security issues on version 2.7.0.
This extension has been added to the subscription packages (iTop Professional and Essential) to protect the application from brute force password attacks. This is indeed a known attack on web applications accessible on the internet.
A Brute-force attack is defined as below by Wikipedia :
In cryptography, a brute-force attack consists of an attacker submitting many passwords or passphrases with the hope of eventually guessing correctly. The attacker systematically checks all possible passwords and passphrases until the correct one is found.
The extension limits the number of possible attempts for the connection, which prevents this type of attack. It also offers many other protections (IP filtering, captcha, …) as indicated in the documentation.
To further complicate the work of hackers, users of the application should not be allowed to have passwords that are too short or too simple. The local authentication system has been modified to control passwords and avoid the validation of too simple and insecure passwords.
More details in What’s new iTop 2.7.0 : Password Policy
Some features definetely had to be included in this LTS. Indeed we needed :
Here are some examples of features that have been implemented to meet these objectives:
Since this version is intended to last, it was necessary to consider the scalability of some parts. The login page was one of the improvements made in version 2.7.0.
We added the following features:
To be able to support the LTS version for a long time, the support team must have tools integrated with iTop to allow them to be more efficient. A special effort has been made in this area.
The iTop application uses, to handle client data, a query language specific to iTop, the OQL (Object Query Language). This language gives access to data by making queries on objects in the way of the SQL language. iTop core then converts OQL into SQL to process what expected by the user.
Before iTop 2.7, the mechanism used to generate these SQL queries guaranteed the consistency of the data returned in the results, which was reassuring for the user, but at the cost of degraded performance.
This part of the application has been reviewed with the objective of improving maintainability, thanks to a more explicit architecture, and the performance of SQL query generation, with a gain in the number of joins (which can amount to several dozen for enumeration operations!)
The optimization choice was made at the detriment of the guarantee of coherence of the results, since the queries will no longer exhaustively search all the tables composing the objects of the client’s data model , but only the tables necessary for the answer (lazy mode). Nevertheless, even if the optimizations depend greatly on the complexity of the OQL queries, an big improvement on the queries execution in the database has been noticed.
This compromise between performance and results consistency was made considering that a tool checking the database consistency called “Database integrity” was provided as part of the application.
This change was made possible by the addition of unit tests validating that the result of the queries was consistent with iTop 2.6.
By listing here all the evolutions both on our organization, our methods, but also the technical choices concerning the solution we’ve made for the Long-term Support, we easily realize the impact of such a project on Combodo teams and iTop solution.
iTop 2.7 has been running for 2 years now, only LTS in parallel with STS versions like iTop 3.0, and used by more than half of our customers. After all this time, we thought it would be useful to end this series of articles with a feedback on the deployment and operation of iTop, in order to prepare the next releases.
The last article of this series will allow you to take stock as we did and put the results of this project in perspective for the future.