This document is geared toward users who have experience in using previous GeneXus versions. Its purpose is to compare the concepts, components and methodologies involved in the development process and Knowledge Base management in previous GeneXus versions and GeneXus X, with its new scenarios.
Previous GeneXus versions:
Models, one design model and one or more prototype and production models. In turn, each one of them had one or more Environments (generators), and one or more Data Stores (DBMS).
In the new version's Knowledge Bases, the available components are Environments (the concept is different from an environment of previous versions), Frozen Versions and Development Versions Environments have one or more Generators and one or more Data Stores.
The main change is the elimination of the Model concept and a different handling of design/prototype/production environments.
The abovementioned components allow us to perform two key tasks: organization of the development process and maintenance of the system being developed.
The organization of the development work involves everything related to what we are developing and how we are developing it. For example, what programming languages we are generating, on what databases the generated applications are running, etc.
On the other hand, maintaining the system being developed involves everything related to versions of the product being developed, delivery of the product to customers, versions of the Knowledge Bases used by the various developers, and so on.
Here lies the first big difference between GeneXus X and previous versions.
In the past, the same components were used to perform both tasks; that is, the same component had different functions depending on the requirement or the user.
In GeneXus X, these tasks and the components used to perform them are clearly differentiated. In addition, in this version the idea is that everything related to these tasks is performed with GeneXus, centralizing all the knowledge in one single location to avoid confusion and inconsistencies.
In GeneXus X, the options associated with this task are located in the Preferences window of the Knowledge Base Navigator, and the components used are the Environments, Generators and Data Stores.
Environments in GeneXus X can be matched to the Prototype and Production models of previous versions, integrated with the Design Model. Each environment has one or more associated Generators and Data Stores.
To generate an application in a new programming language, in a new language or for a new DBMS, what we have to do is create a new Environment with the corresponding characteristics.
There can be several Environments but only one of them will be active (called "Target Environment"), and all the Build options will be applied to it (F5, Build All, Create Database Tables, and so on).
Making an analogy with previous versions, we can say that having several Environments in GeneXus X is the same as having several prototype or production models in previous versions, except that they all share the data structure, that is, the "design model". Therefore, several Environments replace the old synchronized prototype/production models.
In GeneXus X, any change to the data structure (transactions, tables) is applied to all the existing Environments (as if in previous versions an automatic Impact was made of all the prototype/production models), and is taken into account in the following Build actions.
Actually, in previous versions there weren't components or functionalities specific to these tasks. For this reason, we had to make do with what was available to improvise a methodology. This had clear drawbacks such as the lack of consistent concepts and methodologies; each team had its own procedure and the same concept (model, KB) was used with different purposes, thus generating confusion.
In GeneXus X, we try to eliminate these ambiguities, unify concepts regarding these tasks and, lately and most importantly, centralize everything in one single location: the Knowledge Base.
To achieve all this, the Version concept has been introduced. In one Knowledge Base there will be Frozen Versions and Development Versions. These components are managed from the Knowledge Base Versions Tool Window.
Frozen Versions are pictures of the state of a Development Version at a given moment to freeze its state and keep it available for future actions. Making an analogy with previous versions, a frozen version may be associated to creating a new Prototype/Production model, copying Design model information to it, and not allowing further changes.
The canonical example is when an application being developed is delivered to the customer. At that moment, we freeze what we have so far (we create a Frozen Version, which is read-only and separated from the Development Version) for future reference. Then, we continue with the development work on the active Development Version; should we need to correct the customer's version, we can do so starting exactly from what the customer has, in parallel and orthogonally to the development under way. For the customer's corrections we create a New Development Version from the abovementioned Frozen Version.
In the past, this task implied a multiplication of the KB in each delivery to the customer, decentralization and possible lack of coordination at the moment of making corrections or tweaks to these new Knowledge Bases.
In GeneXus X, all this is centralized in the same Knowledge Base, thus avoiding inconsistencies and gaining transparency and reliability of impacts between different versions.
In previous versions, any change to a production model contained the changes made to the prototype model. With GeneXus X, as we work in different development versions, changes in one development version doesn't affect another development version.
In sum, with a vision oriented towards previous versions, each Frozen Version would be a different and independent KB (but created from another), which has its own Environments (with the corresponding Generators and Data Stores), its own data models and so on. Following the analogy with previous versions, a GeneXus X KB contains all the KBs used in previous versions for managing and maintaining application development.
The new functionalities enable more expansion and simplification of the maintenance options; for example, in the same Knowledge Base we can now have several versions (most likely, different) of one application delivered to different customers. Thus, they can all be easily and transparently upgraded to a new version of the application or to a fix in particular.
|Concept in previous versions
||Concept in GeneXus X
||Part of the Environment containing the logical representation of the system
||Part of the Environment containing the execution platform information
|Several environments in one prototype/production model
||Several Generators in one Environment
|Several DataStores in one prototype/production model
||Several DataStores in one Environment
|Several synchronized prototype/production models
||Several environments in the same development version
|Different unsynchronized prototype/production models
||Different development versions (to be exactly the same, both versions should have the same data structure, as in the previous version they share the "design" and now they don't)
|Adding a new execution platform for the application
||Adding a new Prototype/Production model with adequate platform information
||Adding a new Environment, with the appropriate generator and data store
|Changing Design model properties
||Changing Properties in the Master properties windows (Edit Model) of the Design model
||Changing root node properties in Preferences windows
|Changing Prototype/Production model properties
||Changing Properties and DBMS options in the Model Properties windows (Edit Model) of the Prototype/Production model
||Changing Environment, Generator and Data Store properties in Preferences windows
|Take the application into production (release)
||Adding a new Prototype/Production model and building the application from that model
||Freeze a version from the development thread (usually the trunk), create a new development version from the created frozen version and build the application. All within the same KB.
|Freezing a version for delivery to a customer
||Physical duplication of the KB
||New frozen version of the same KB
|Storing different frozen versions delivered to different customers
||Physical multiplication of the KB
||Several frozen versions of the same KB
|Correcting an error or tweaking the released version
||New duplication (by backup) and modification in another KB
||Creation of a new development version from the frozen version and modification in this new version. All within the same KB.
|Upgrading a customer's application
||Impact of the production model, build the new application and replace the older with the new one
||Freeze a version from the development thread, and create a new development version from the frozen version. Then, using this development version, we generate the application and replace the older with the new one.
|Upgrading several customers (with different released versions) to a new version.
||Impact on production models of different KBs which are completely independent from each other (prone to lack of synchronization).
||Freeze a version from the development thread, and create a new development version for each customer, from the frozen version. Then generate the application for each customer. The entire work is done on the same KB, thus ensuring synchronization.