Year: 2015

Outside of the Database World (Java, JavaScript etc..) developers use version control systems more effectively. When used appropriately in the software development life cycle, a version control tool can shorten delivery times significantly by improving the manageability of the code base.

Using version control with PL/SQL (and other database objects) has always been challenging. In our experience very few, if any, IT departments use version control systems to manage their database. Most are content with a basic check-in check-out mechanism.

We created Gitora to help database developers manage their code base better. Gitora achieves this by bridging the gap between the Oracle Database and Git, the most prominent and popular version control system used by millions of developers around the world.

With Gitora you can:

• Perform the version control operations using a point and click interface. This reduces the barrier to entry for Git. Only a basic understanding of version control principles is good enough to get value from the product.

• Move your code base automatically to a specific version (for example to match it to the version in production.)

• Create new branches to work on new features without affecting the master code base.

• Change between different branches of your code base automatically.

• Merge your branches to the master code base automatically.

• Push your changes to remote repos in cloud services such as GitHub, GitLab and BitBucket.
• Pull changes from other databases and merge these changes with your database code.

• Browse the Git repository and see your commit history and changes associated with each commit.

Collaboration vs. Parallel Development

Gitora can be used in collaboration mode in which all database developers work in the same Oracle Schema(s). In this case Gitora supports a check-in check-out mechanism. This check in/out mechanism is tool independent. It works with SQL Developer, TOAD and PL/SQL Developer (or any other tool for that matter).

More importantly, Gitora can also be used in parallel development mode in which every database developer works in her own schema(s). In this way of working, (which is exactly how Java, .NET, JavaScript developers etc.. are working) each developer has her own copy of the database code and is free to make changes to them related to the task she has at hand. In parallel mode, no developer blocks the other because she is the only one who checks out the objects in her own schema(s). This improves development times significantly because more than one developer can work on the same logical object at the same time.

The software development team establishes a workflow to merge the changes of each developer and propagate these changes to the master code base. Gitora (via Git) also helps with this process with automated merging of changes. In the event of a conflict (where Git cannot figure out how to merge changes done by two developers to the same code unit) Gitora asks the user to resolve the conflict. Gitora creates multiple versions of the database code objects in question and helps the developers to resolve the issue. (Please see Introduction to Gitora, Git for PL/SQL developers for more information on this topic)

Best to our knowledge, Gitora is the only tool that is specifically designed to be used for parallel development with PL/SQL. We think parallel development is where a software team starts to get a lot of value from using a version control system. This helps establishing a formal workflow of incorporating changes to the master code base and to production.

Gitora integrates to your software development lifecycle. We cannot overstate how important this is. Gitora is not something you do on the side and it does not have back doors where you can circumvent version control. It becomes an essential part of your daily workflow. There are version control tools that people use on the side by copying and pasting scripts. This is a very error prone process because it requires developers to “remember” to do version control. Some version control tools only work within a specific tool (such as TOAD) and do not prevent the developer from opening another tool (such as PL/SQL developer) and modify code without using proper version control mechanisms.

For more information about Gitora, we recommend you to visit the following links:

Gitora Webinar Recording (and Slides)

Six Common Question About Gitora

What is the Difference between Gitora and SQL Developer’s Git Interface

Below you can find the recording and the slides of the Gitora Webinar. Thanks to everyone who attended. What a turnout!

Introducing Gitora, the free version control tool for PL/SQL from Yalim K. Gerger on Vimeo.

Recently. we received an email from a Gitora user with six questions. We think our answers might be interesting for others as well. So here they are:

1. Where is the remote repository created?
Gitora does not use a remote repository in its first version. Everything is handled using local repositories. You can still use a remote repository if you want. There is nothing in Gitora preventing you from doing that.

2. How do you lock database objects?
The users decide which database objects Gitora should manage. When a DDL is executed, a database level trigger created by Gitora ensures that the Oracle user running the DDL is signed in to Gitora and checked out the database object it is manipulating if it is an object managed by Gitora. If the object is checked out by another user already, the trigger throws an exception. There is a PL/SQL API for a database user to sign in to Gitora in her database session. Optionally, she can use the Gitora App to check out an object. Gitora is also quite pragmatic and automatically checks out the object if it is not currently checked out by anyone else.

3. Is there any relation between Gitora users and Database Users? If there isn’t any relation, how do I create Gitora users?
There is no relation between Gitora users and database users. You can use the Gitora App to create Gitora users. Then, to check out an object managed by Gitora, you can sign in to Gitora by either using its PL/SQL API or the Gitora App.

4. Do I have to log in to Gitora every time I create a new database session?
You have to log in to Gitora in a database session only if you want to modify a database object or check out a database object managed by Gitora. Signing in is a single line API call that probably can be automated by your PL/SQL development tool.

5. Where is the version history stored?
Everything related to versioning is done and stored in the Git repository. Gitora is only a bridge between the Oracle Database and the Git server.

6. How can we integrate Gitora to TOAD? Is there a plug-in?
There is no need for a plug-in. Gitora works with any PL/SQL development tool. It has a small set of PL/SQL API’s that you can call from any development tool. Gitora also has a web app you can use to perform common version control tasks.

We’ve been getting this question a lot lately, so I thought it is a good idea to write a blog post about it.

In SQL Developer, you work in two ways:

• You edit objects in the database and then you manually create files in a folder managed by Git.
• You edit files managed by Git and execute them in the database.

SQL Developer helps you run Git commands on these files. When you issue a Git command that changes your code base, you have to manually carry over the changed code units to the database by running the scripts.

In Gitora, if you modify a PL/SQL code unit in the database, you do not need to manually copy the updated script to a folder managed by Git. Gitora does that automatically. Similarly, if you issue a Git command using Gitora’s point and click interface, Gitora automatically updates the PL/SQL code units  in tha database. Gitora also has a check out mechanism that works at the database level, meaning that if you check out a PL/SQL code unit, no one else can edit it until you release or commit it. This is enforced at the database level. So there are no back doors.

So the advantages of Gitora’s approach are:

– A lot less manual work. Every edit you make is synced to the file system by Gitora. Every Git command you execute, updates your database code automatically.

– A lot less human errors. Copying files back and forth manually is very error prone.

– Much easier team work. Gitora’s check out mechanism prevents others from making changes to objects you are working on.

– Well structured working directory. Gitora creates a well structured working directory with reasonable folder and file names for database objects. The locations of these files are also standard. When there is human decision involved with naming and putting files in the file system, a lot of errors can occur. Gitora prevents these errors.

– No back doors. Gitora enforces that if an object is being edited by someone, no one else can edit it. Version control is not something you do on the side but it is tightly integrated into your workflow and enforced.

– It works with any editor. You can use SQL Developer, SQL Navigaor, TOAD or PL/SQL Developer. It doesn’t matter. Everyone in your team can use a different editor if they choose to do so. Gitora still works.

Yalim K. Gerger