1 – Travel to the past
The change log provides all the information we need about what changed, when, and why. It allows us to answer questions such as “what did I change last week that may have broken things?”
Sure, even without GXserver, GeneXus also provides a per-object change log, automatically creating a revision each time the user saves an object. But the change log in GXserver goes far beyond that, for any time we commit changes to the server we are defining a logical group of objects that we changed at the same time and with a specific and stated purpose (ie: commit comments). Comments in the commit may also contain a reference to a ticket number in any bug tracking or project management system.
When something goes wrong, we have all we need to revert our mistakes. Many times the changes in one object are related to changes in other objects. For example, when we change the parameters of a procedure, we also need to change the objects that called it. Identifying all the objects that changed in each commit allows us to make sure that we are fixing all that needs to be fixed.
Likewise, context information is very important when we need to understand why we made some change to an object. For instance, we may want to check other objects that changed at the same time and even what were the contents of those that didn’t change.
2 – Version managementOf course we can have frozen versions and development branches in a KB without GXserver, but with it we can also easily publish any of those branches to external processes, and to build or continuous integration servers, in a decoupled way and without the performance penalties of sharing a KB through a network share.
In the KB we use for development work, we only need the branch to which we are making commits, and we can keep all the frozen versions and development branches in the server. A continuous integration server may monitor all the commits we make to any of the branches to trigger builds, tests, deploy processes, etc.
3 – Free to experiment
Using a local KB, we can freely experiment without worrying about impacting the “official” version unless we explicitly commit our changes. Once we are ready to make a commit, we can check the list of pending changes, compare each object to its original state, and choose which objects to include in the commit, which to easily revert to the previous state, and which to retain as local-only changes.
GXserver checks that the set of objects in the commit are consistent (for instance, that we aren’t adding a call to a new object that we forgot to include), and rejects the whole commit otherwise. This is done to make sure that every commit is a complete logical unit of change and that we never break the integrity of the KB in the server.
4 – Easier backups
With GXserver, we never need multiple copies of the same KB and we are always sure exactly what we need to backup: just the KBs hosted at the server. As long as we make commits and have an appropriate backup policy over the KBs at the server, we are insured against loss of local KBs due to hard disk failures, stolen notebooks or the like.
If we are using GXserver Online (subscription to GXserver service in the cloud), we also have automatic backups for all the KBs.
5 – Online KB browsing
GXserver provides a web console where we can browse the existing KBs, their objects, and the change activity. GX is not necessary to do this, as any web browser is enough. If we have GX and the KBs at the office, we can still use this console from home or while travelling.
6 – Integrating other actors
Access to the GXserver console can be granted to other people who are not developers but are involved in the project and need to monitor its progress, such as managers or the customers who hired us to develop their software.
Besides, software development usually requires many other actors in addition to the actual developers, and they can use the console to get information directly from the KB, without actually having it and even without a GX license. This may be the case of people writing documentation, translators, or graphic designers.
7 – Anytime, anywhere
Even if we are the only developer on a project, we can benefit from being able to obtain an updated copy of our KB from anywhere. For example, we may have one local KB at the office and another copy at home, both easily synchronized through GXserver.
In the event that we need to add a new developer, either permanently or for a limited time, he or she can easily obtain a new working KB at any time and from anywhere.
In summary
Using a version control tool and its associated methodology is one of those things we may think we don’t need, until we actually start using it. Then we realize all the benefits it brings, and we can’t believe we ever lived without it.
The most well-known advantage of using version control systems is the ability to easily integrate multiple developers into the same project, giving all of them an isolated and autonomous environment while ensuring effortless integration of work.
However, there are so many advantages in using a version control, even for a single developer, that it’s a must-have in any professional software development project. The above advantages are the most outstanding, but of course you may find many more.
In fact, all of this isn’t specific to GeneXus or GXserver; it’s equally valid for any software development project using traditional languages, and any time the question is raised, the answer is the same: using a version control system is the best option, even for a single developer.
*
Blog de José Lamas