If you want different results, then do not do the same things’ Develop software in a different way!

Rolling Release Software: Learn all about it here

“Rolling Release software” is a model that has been extended in recent years due to the rise of the Internet and the technological development of its users. In Pandora FMS we announced in March 2017 the release of the version 7.0, therefore we started the Rolling Release software, but what does this mean? What are the advantages? Let’s take a look!

Introduction to Rolling Release software

As we have already mentioned, since version 7.0 in Pandora FMS we have embraced the Rolling Release software model, so the way of numbering the different versions involves a remarkable change. Thus, previously, we used the traditional way of releasing the version and then from version 6 onwards we included different Service Packages (“Service Pack” or “SP”).
In a brief summary we will show you how the name of the version has evolved over the years (in Wikipedia you will find an excellent article with more details):

• Version 1.0: October 2004.
• Version 2.0: September 2008.
• Version 3.0: December 2009.
• Version 4.0: August 2011.
• Version 5.0: October 2013.
• Version 6.0: November 2015.
• Version 7.0: March 2017.

Rolling Release software

It is a huge thing to study this model of software development and we could write thousands of words. But let’s have a look at what a famous inventor once said:
“Simplicity is the ultimate sophistication.”
Leonardo Da Vinci

So we will follow the advice of the famous Italian legend and we will explain to you the concept of Rolling Release software with a practical example.

We are marine engineers

Imagine that we are a marine engineer and a shipyard hires us to build a boat. He specifies the number of passengers, the width, the length and the purpose of the boat (for fishing, competition, etc.). This small project will not be a problem for our knowledge and it will not be hard to do. Likewise, a small software that carries out a small task will not be a setback in terms of development.

A boat over the Mediterranean and into the Greek islands

Well, it turns out that this shipyard is now hiring us to design a cruise ship to accommodate thousands of people, with specific facilities and under the laws of the European Union. This way we will spend several years with the project managers because it is very difficult to carry out on our own.

Imagine that we live in the early 1900s: we will have to hire hundreds of designers and thousands of builders, specialized workers who know how to draw plans and with minimal knowledge of engineering but with great skill in manual labor. Let’s take a closer look at this play.

Requirements

It is essential to have in detail the characteristics of the boat to be designed, as well as the countries it will visit, the facilities it will have and, especially, the expectations of the final customer who will buy the boat.

Design

We will meet here with our fellow marine engineers and we will assign teams for different purposes: those who will design the bow, another group of cabins, the engine room, the kitchens and dining rooms etc. Everyone must know what to do, at least in theory.

Deployment

During the design phase, the different parts of the ship will be manufactured while the shipyard will have received our plans and will have chosen the dry dock in order to start building the shell and the components will arrive as well. This modern construction process is inspired by the process chain invented by Henry Ford and the concept of fair inventory: only the parts, pieces and materials will be there when the ship is assembled.

Verification

At the shipyard, they will not be able to assemble the ship just like that: when taking the parts that make up the ship, they will have to measure and weigh to confirm that they are designed according to the copies of drawings received. Once it’s confirmed that everything’s okay, it’ll be lifted by the cranes. In this phase we will notice the design errors: if the engine or engines received are in accordance with the plans and then proceed to their assembly, right there we will notice that they do not fit in the engine room. Not only will we have to deal with design errors, it may happen that one group of designers has done the same work as another group, a mix-up in assignments and we will have duplicate work, and we will also have work to do. Verification is also about that, it is about what you have yet to receive to begin the assembly.

This is where the loss of time and expense will begin in order to adjust and not lose all the effort and work that has been done, if there is a solution.

Maintenance

Once we have overcome all the obstacles we will see our brand new ship ready to float in the Harbor for its first tests. The maintenance phase will begin as soon as it gets wet, even if it is correctly painted and with electricity circulating through its metal parts, the fight against corrosion will continue until the end of its useful life.

Cascade model

We have just explained the activities of the software development process but they are carried out according to the cascade model, which has its advantages and disadvantages:

• There is central control of the project, efforts are well managed.
• It is difficult to exceed the initial cost as everything has been planned therefore the guidelines and schedule should be followed accurately.
• The bad news is that the process is sequential, and until one phase is completed, it will not pass on to the next one.
• If the shipyard forgets to make a specification, the addition of this will mean a higher cost.
• When materials and parts arrive and assembly and welding begin, we will then notice the design flaws.
• The shipyard does not participate in the design process, therefore his or her observations in order to correct or improve the design are not considered by us.

A ship made according to the Rolling Release software

Welcome to the 21st century

At this point in this century, the work of designing and building our “great luxury boat” with new software tools will allow us to move forward a great deal. While software development activities are repeated (because building a boat will always have the same goal in the end) the way or model we choose will make the difference. We will specifically use new design tools that will expand our horizons.

Requirements

The beginning is almost the same as the example we proposed earlier but with a big difference: we will be able to revisit the requirements to modify them or even to add more requirements, let’s read on to find out how.

Design

Here you can see the differences of the model: the Rolling Release Software implies the Rolling Software Integration with or without the Rolling Software Implementation.

To recap, it would be: Integration, Release and Implementation (of Rolling software).

Let’s get back to our ship: in the design phase our fellow marine engineers will work on their assigned designs with CAD software (and they won’t be able to choose another one because their user credentials won’t allow it) and once they feel they have finished a goal they will “upload” it to the rest of the project which is located in a repository which is not just a simple storage place. An early advantage is that it will be possible to determine automatically if what is proposed by one group has an impact on another working group, while alerting us so that we can decide what is assimilated and what is rejected (this is called collisions).

But the most important part is that we will have software that will take all the plans (actually drawings made in 3D virtually) and will first verify each of the individual components assigned to each team and then assemble the entire boat virtually and then it will generate a report of the result stating the possible errors found and whether the project requirements have been exceeded.

If you have any problems, you will be able to contact those responsible for the incident so that they can take the necessary measures so it does not go any further. Another advantage is that we can assign credentials to the teams at the shipyard so that they can review and comment on the project so that it is fully integrated.

Implementation

Components that are already designed can be manufactured and shipped to the harbor to save time. From here we can thank the project that these pieces arrived and confirm the chronological health of the creation.

Verification

You can also check the components and upload them to the repository so that each time the designers “upload” their steps and perform the virtual assembly, in order to confirm that what is already there physically corresponds to what they have just designed. Here you can even tell if you have “too many parts to spare” and then go back to the design (or the project manager can decide if he or she will do without that part for good). This will be considered a loss, even if they manage to sell the material at a good price, the time lost (in design and manufacturing) cannot be recovered, but the good quality of the product will be saved.

Maintenance

Once at sea the maintenance phase begins, we will work with minor and major repairs, but there may also be other events that push the design back: the boat is now bound to be an ocean liner to visit the Caribbean islands, where powerful winds drive the waves, so we will have to add some stabilizers… and again we will have to go back to the design “table” to repeat the cycle to return the ship to the shipyard!

Rolling Release Software

Now we can talk properly about developing a program. Let’s talk properly about the definitions:

• Continuous integration focuses on integrating the work of individual developers into a master repository several times a day to detect integration errors early and accelerate the collaborative development.
• Continuous delivery is all about reducing friction in the implementation or release process, automating the steps necessary to implement a compilation so that code can be safely released at any time.
• Continuous deployment goes even one step further by automatically deploying it every time you make a code change.

Continuous integration

As we explained in the example of the design of the ship, the Continuous Integration of software consists of programmers putting all their work back into the repository at the end of the day (and even several times a day), but how does this work? In order to explain the control of software extensions we need to look back a bit on history to find out where we come from and where we’re going…

Linus Torvalds, rsync and git: a short summary

In 1998 it was difficult for Linus Torvalds to coordinate the development of the Linux kernel and it wasn’t until the year 2000, when software capable of controlling the versions in a practical way was born. In that year the Apache Subversion (abbreviated as SVN) arrived. But Linus was still not satisfied, so in 2002 they decided to ask a company to design a software project to control the versions of any software development, which did not turn out as expected. Although the program presented important new features, which were useful and still valid, it was also partially private, which brought friction with the free software community. Naturally, Torvalds asked Andrew Tridgell (also father of rsync and Samba Server) to develop a solution, and it turned out that rsync would be the basis for it. In 2005 Git was born (and Mercurial, another version control software, was also launched) and today these three alternatives dominate the vast majority of the programming market.

One of the new features imposed by Git was that each programmer in turn had a copy of the main repository, so every person in the team can have a copy of the main repository, if this disappears it can always be recovered through the combination of an orderly and logical way of each of the copies so the issue of data backup was practically resolved.

He also introduced branch-based development: a programmer with a full copy of the project can open a branch in parallel and “upload” his or her changes back so that the team can either add it to the main branch or discard it once and for all. This is more than enough, but what does it have to do with Rolling Release Software?

Short branches of development

Since Rolling Release Software depends on Continuous Integration it must be done frequently and with very short branches, which must be quickly incorporated into the main branch. The aim of these short developments is to use another innovative procedure.

Frequent software compilations

Through software that is constantly reviewing the main source code, by applying smoke tests to individual components and then to the entire project and then compiling and even applying soak tests, it can be determined very quickly and directly whether recent changes work and meet the project’s parameters. As we mentioned in our example in the construction of a passenger ship, automated compilations when updating the source code frequently allow us to interact and check the process chain in software development.

Conditioned software compilation

This automated model has an additional benefit for us: it is possible to add new options that are disabled by default for users, but what is this for? Well, in order to offer consumers alternatives.

Continuous Software Release

Continuous Software Release is the next step after Continuous Integration. This involves offering new updates automatically, modifications or improvements made to the software through the process chain. In our application repository we will then have published the files needed for the new version ready for download, now it will depend on the software installed on the client side to connect to the repository, and look for the differences and show them to the user either through a warning on the desktop of our application or through a discreet pop-up message. However the user does not necessarily have to receive a message saying that an update is available, let’s go to the next level of sophistication in a simple way.

Continuous Implementation

Imagine that you have thousands of customers and everyone, or at least the great majority, has expectations of new versions to make their daily work easier, any improvement is always welcome.
One of these days the publication is announced in our repository and hello! thousands of devices connected at the same time…. even if we have a Content Delivery Network (CDN) this will cause us some problems. First in our repository, if you have a load balancer and mirror servers of the repository, it will eventually overload or even collapse. And if we have a CDN service it will be painful for us to touch our company’s money, because when the traffic has a sudden peak or increase it is additionally charged.

This is where Rolling Release Software and Continuous Deployment take place: in fact, the changes in each version are small but constant.

But also Continuous Deployment allows such updates to be downloaded and installed in the background but disabled by default while waiting for the corresponding public announcement. An additional advantage is that it also allows us to track which companies have decided not to update in order to be able to conduct an approach or survey.

Now imagine the look on our users’ faces when they see the announcement of a new version available and the question “Do you want to install the new update?” and in a matter of a minute or two the process is newly activated, do you remember the conditioned compilation? The surprise and satisfaction of a good and transparent software update to our customers is well worth the hard work of changing the development model: the Rolling Release Software arrived to Pandora FMS to stay and is extremely useful.

Conclusion

All this is possible through the technological development that we have acquired, since we began to program and save on floppy disks in the 80s we feel confident and with great expectation about this tremendous opportunity that opens up a new roadmap for everyone.

And remember, “Pandora FMS” means “Flexibility” and the Rolling Release definitely shows this. Along with our commitment to bring you the most powerful Open Source monitoring tool on the market, see you soon!