Best Practices When Using the Integration with a VCS¶
General Best Practices¶
This section lists general recommendations about how to use the support for VCS:
- Create a different database for each project.
- Use the VCS integration during the development process because developers will be able to share their work easier.
Tagging and Branching Releases¶
We recommend setting up a process to create tags and branches in the VCS, in order to manage the versions that a project goes through during its life.
Consider the following ideas:
- Add a tag to the repository every time you deploy a database to testing and production. This ensures that a project can be brought to the exact state it was at the time of a release so developers can track issues.
- Create a branch for each major version of a project if several versions of the same project must run in production at the same time. This may be necessary when a new version of a project introduces changes that break the backward compatibility and client applications cannot be updated in time.
- If there is no companywide standard regarding the names of branches and
tags, a good naming convention for tags and branches is adding the
version number to the end of the project. For example, if the project is
called project1, the branches would be named project1-X.Y.Z and the
tags, project1-vX.Y.Z (the v, indicates that that element is a version),
- X is the major version. Major versions are defined as versions that break backwards compatibility or that bring substantial changes to the project.
- Y is the minor version. Minor versions are versions that do not include big new features and that do not break the compatibility with client applications.
- Z is the revision number. Versions that have small changes such as the ones introduced to fix small issues in the views created, performance improvements, etc.
To tag and branch the different versions, you can use a client tool for the VCS you are using (e.g. for GIT, you can use SourceTree), check out a copy of the repository where the database of the project is on your local machine and add the tag/branch.
Managing Global Elements¶
This section provides guidelines about managing global elements that are checked in the VCS server.
In Virtual DataPort, the following types of elements do not belong to a specific database and are shared across the entire Server:
- I18n maps
Of these elements, jars and i18n maps can be put under version control. The fact that these two elements are common to all the databases, may introduce some issues. For example, let us say that project1 and project2 reference the custom wrapper X. Then, the team for project1 needs a new version of the custom wrapper X and the changes in the new version are not backward-compatible. If the team uploads the new version of the jar, some parts of project2 will stop working properly.
To avoid this problem we recommend using naming conventions when uploading jars to the Server.
Prefix the name of the jar with the name of the database that uses it. To do this, rename the jar before uploading it to the Server.
You may end up with the same jar uploaded several times with different names. The benefit is that if one of the projects needs to update that jar, it will not affect the others projects.
If you expect that one Server may have two databases belonging to different versions of the same project, add the version of the project as a suffix of the name of the jar. By doing this, each version of the project will use the appropriate jar.
The administrator should be in charge of uploading new jars and checking them into the VCS. That way, she can make sure that the jars follow these naming convention.
Recommendations for the Testing Environment¶
When possible, the testing environment should be similar to the production environment. That is:
- The configuration of the hardware/virtual machine where the Denodo servers run should be similar.
- The data used should be representative of the data that will be found in production.
- The performance of the data sources and network should be similar.
These guidelines ensure that the conclusions drawn from the tests performed on the testing environment will apply to the production environment.