We’re happy to announce the general availability of Gitora 4.
Gitora 4 builds on top of the great foundation of Gitora 3 and makes it even easier for Oracle developers to integrate version control to their daily workflow.
Gitora 4 comes with three new improvements:
Today, we’re happy to announce the general availability of Gitora 3.
Gitora 2 enabled developers to manage database objects that support the CREATE OR REPLACE command, namely PACKAGES, PROCEDURES, FUNCTIONS, TRIGGERS, VIEWS, SYNONYMS and TYPES in a Git repository. (In Gitora terminology, we call these “Soft Objects”).
Gitora 3 goes a step further and enables developers to manage every database object in an Oracle Database with Git even if the object does not support the CREATE OR REPLACE command. (In Gitora terminology, we call these “Hard Objects”.)
Specifically, Gitora 3 allows developers to manage TABLES, INDEXES, SEQUENCES, CONSTRAINTS, TABLESPACES, MATERIALIZED VIEWS and every other schema or non-schema objects with Git.
Let’s examine how you can manage these objects with Gitora 3 with an example.
Gitora 3 introduces the concept of a Managed Schema. A managed schema is an Oracle Database Schema that Gitora tracks for execution of Hard Object DDL’s. In other words, you register one or more Oracle Schemas to a Gitora repository. Once a schema is registered to a repository, Gitora will track every hard object DDL executed for that schema. A repository can manage many schemas but a schema can only be managed by one repository.
In the Gitora App, select a repository. Click Local Commands –> Add/Remove Managed Schemas menu option. A dialog shows up.
Select the schema(s) you’d like to manage.
Click OK. The dialog closes. The screenshots above show the HR schema being added to a repo as a managed schema.
After a schema becomes managed, Gitora creates a new package in the schema automatically. This package is always called GITORA_MODEL[X] where [X] is a unique number that identifies the package. In our example above, Gitora created the GITORA_MODEL1 package in the HR schema and added this package to the Git repository which is managing the HR schema:
The screenshot above tells us that repo1 is managing the HR schema.
There are no changes in Gitora 3 for soft objects. You continue managing soft objects just like you’ve been managing them with Gitora 2. In other words, any repo can manage any number of soft objects and any number of schemas.
To demonstrate this let’s add a dummy package called PACKAGE1 to HR and manage it with the same repo named repo1:
Select Local Commands –> Add/Remove Soft Objects menu item. A dialog shows up where you can select which soft objects you’d like to manage with repo1. Note that, GITORA_MODEL1 package shows up as a managed package because it was automatically created to manage the hard objects in the HR schema.
Add PACKAGE1 as a managed package and click OK. The Gitora App shows the following object list for repo1:
Let’s execute the following DDL statements for the HR schema: (Note that in the database session we first have to log in to Gitora with a valid Gitora user. In this case, we logged in as admin.)
[sql]
ALTER TABLE COUNTRIES MODIFY (COUNTRY_NAME VARCHAR2 (200))
ALTER TABLE EMPLOYEES ADD (MIDDLE_NAME VARCHAR2 (25))
ALTER TABLE COUNTRIES ADD (CURRENCY_NAME VARCHAR2 (200))
[/sql]
Finally, let’s also modify a soft object and add a new dummy function to PACKAGE1 called function1.
To commit our changes, let’s switch to Gitora App and click the commit button. The My Objects Dialog shows up, displaying the list of soft objects and hard object DDL’s ready to be committed to Git. Note that the dialog only shows the changes made by the signed in developer:
In this dialog, you can choose which packages or hard object DDL’s you’d like to include in this commit by checking/unchecking the checkbox in the Include? columns of both grids.
Note that, the commit registers the package update and the table DDL statement as a single logical commit which is a key benefit we’d like to get from the version control system.
After the commit, we receive the following message from Git:
Note that, the Git commit not only included PACKAGE1 but also the GITORA_MODEL1 package. After the Git commit is successful, the new GITORA_MODEL1 package code looks like this:
[sql]
CREATE OR REPLACE
PACKAGE BODY gitora_model1 IS
function doModel return clob is
v_log_cl clob;
v_ddl_cl clob;
v_cursor_int integer;
return_value integer;
procedure log(in_text_cl clob) is
begin
v_log_cl:=v_log_cl||in_text_cl||chr(10);
end;
begin
/*GITORA GENERATED COMMENT. DO NOT EDIT OR REMOVE. ONLY WRITE CODE UNDER THIS LINE.*/
null;
/*SCRIPT FOR HR.COUNTRIES by user:admin */
begin
v_ddl_cl:=’ALTER TABLE COUNTRIES
MODIFY (
COUNTRY_NAME VARCHAR2 (200)
)
‘;
log(v_ddl_cl);
execute immediate v_ddl_cl;
log(‘DDL executed successfully.’);
exception
when others then
log(‘ERROR:’||’ ‘||SQLErrm||’ ‘||dbms_utility.format_error_backtrace);
end;
/*SCRIPT FOR HR.EMPLOYEES by user:admin */
begin
v_ddl_cl:=’ALTER TABLE EMPLOYEES
ADD (
MIDDLE_NAME VARCHAR2 (25)
)
‘;
log(v_ddl_cl);
execute immediate v_ddl_cl;
log(‘DDL executed successfully.’);
exception
when others then
log(‘ERROR:’||’ ‘||SQLErrm||’ ‘||dbms_utility.format_error_backtrace);
end;
/*SCRIPT FOR HR.COUNTRIES by user:admin */
begin
v_ddl_cl:=’ALTER TABLE COUNTRIES
ADD (
CURRENCY_NAME VARCHAR2 (200)
)
‘;
log(v_ddl_cl);
execute immediate v_ddl_cl;
log(‘DDL executed successfully.’);
exception
when others then
log(‘ERROR:’||’ ‘||SQLErrm||’ ‘||dbms_utility.format_error_backtrace);
end;
/*GITORA GENERATED COMMENT. DO NOT EDIT OR REMOVE. ONLY WRITE CODE ABOVE THIS LINE.*/
return v_log_cl;
end;
end;
[/sql]
The GITORA_MODEL packages contain the DDL statements you commit to your Git repository for the schema they are in. You can edit them any way you’d like to change the DDL statements, call other functions and procedures etc… In other words, they are no different than any other package you are managing with Gitora.
GITORA_MODEL.doModel function executes the DDL statements stored in the package. You can use the doModel function to execute the changes in a target database. For example, after development is completed for a new version, you can pull the new version to from DEV to the TEST database and simply execute the GITORA_MODEL.doModel function to transfer the hard object updates to TEST.
Errors during its execution does not prevent the doModel function from executing remaning DDL statements. The function captures these errors and returns them as a CLOB value. This way, the same GITORA_MODEL package can be executed many times even if contains DDL statements that are previously executed in the target database (because these statements will silently fail). The GITORA_MODEL packages requires minimal maintanance, if any at all.
Not every database object has a schema. For example, TABLESPACES do not have an owner schema. DDL statements for non-schema objects are tracked by Gitora if the Oracle User(schema) who executed the statement is being managed by Gitora. For example, in the case above, if a DDL statement to create a TABLESPACE is executed by the Oracle User HR, then this DDL will be tracked by repo1.
Similarly, any GRANT and REVOKE statement will be tracked by the Gitora repo which is managing the Oracle User(schema).
You may not want to manage every object or object type with Gitora. Moreover, you may want to define complex rules to decide which object is managed by which repo. Customizing what types of objects Gitora should manage and in which repo is very easy using PL/SQL. Gitora uses four database level DDL triggers to detect DDL statement execution. By editing these triggers, you can define any kind of rule you like.
For example, a common rule used by Gitora customers is to allow developers to create tables for testing purposes. These tables do not need to be managed by Gitora. One of the easy ways of implementing this rule is to tell developers to use a certain prefix such as Z_ for test tables, and exclude any table DDL statement from executing Gitora API’s in the four DDL triggers if the table name starts with Z_.
Gitora 3 is a free upgrade for all current customers. Please allow us 2-3 weeks to send us your new license scripts.
We’ll have more tutorials and webinars about Gitora 3 in the near future. Now download the Gitora 3 trial and start playing! 🙂
This articles is about agile development using multiple (pluggable) databases. If you are trying to implement an agile workflow using a single database please read this article.
Here is the number one question we receive from PL/SQL developers, DBA’s and IT managers who are implementing a version control solution for their Oracle Database:
Developer 1 (or Team 1) works on Feature A (or issue A, bug A, project A). Developer 2 works on Feature B. Both developers make many changes to the PL/SQL code and many commits to the version control repository. We move to testing. Based on the test results, even more commits are made by both developers. Now at the last minute, due to some reason we decide to ship Feature B only. How can we remove Feature A from the source code easily? How does Gitora help in such a situation?
There are multiple answers to this question. Below, I’ll go over two possible solutions for two potential setups:
Let’s assume that our shared development database is called DEV. In other words, both Feature A and Feature B are being developed in the same code base. Let’s also assume our only test database is called TEST.
Finally, assume that DEV and TEST are managed by Gitora. All version control operations are done with Gitora.
In this case, the commit history of the DEV repo has changes both for Feature A and B in a random order and looks something like this:
There is no easy way to remove the commits for Feature B in this setup. If the team decides to deliver Feature A to production but postpone the delivery of Feature B here are the steps they should follow:
At this point the commit history in the DEV repo looks something like this:
And finally, the next steps are:
In such a setup Gitora provides the following benefits:
The downside of this approach is that it involves manual work which is error prone. Developers still have to manually go through the commit history and make the changes to the source code in DEV to disable/remove Feature A. With only one shared development database, there is no easy way to remove Feature A.
Now things get more interesting. Below is a simplified workflow that uses only two development databases. This setup enables the IT team to deliver only the Feature B without manually editing PL/SQL code objects to remove Feature A.
Here is our initial set up:
Developer 1:
As an example, the Git history in Gitora DEV1 looks like this:
Developer 2:
The Git commit history in Gitora DEV2 looks like this:
At any point in time, if Developer 1 or Developer 2 decides to send code to TEST (for example, for integration testing purposes..), they follow the steps below.
Please note that in real world development, the workflows described below can be performed simultaneously in DEV1 and DEV2, in no particular order, any number of times until both features are ready to be deployed to production.
The steps below are merely a simplified example of how this workflow takes place.
Developer 1:
Developer 2:
In other words, in its final state, the source code in the TEST database is a merge of Feature A and B where the commits in TEST/master branch are combined. In our example, the full commit history of DEV1, DEV2 and TEST repositories look like this:
Note that at all times, DEV1/featureA only contains the code for Feature A. Similarly, DEV2/featureB only contains the code for Feature B.
This workflow enables the IT team to exclude Feature A from the next deployment at any point in time before going to production.
To achieve this in our example, follow the steps below:
After these steps are completed, the TEST database only contains code changes related to Feature B. We can use Gitora to extract a DDL script which contains only the changes made between the initial and final state of TEST/master and use this script to deploy the new version which only includes Feature B to the production database.
Gitora helps developers execute this workflow with a point&click GUI. Specifically:
Therefore:
Download Gitora now and try this workflow in your environment.
This week I hosted a webinar for ODTUG members about how to implement a version control solution for the Oracle Database using Git. Many thanks to the 119 attendees who joined the live event. I am very happy to see that version control is now being recognized as a serious pain point among Oracle Database customers.
Please see below for the video and the slides of the presentation:
Last week, we hosted another webinar to talk about Gitora and how it helps Oracle developers manage their PL/SQL code base. Below are the slides we used during the webinar:
You can watch the recording of the webinar below:
Gitora is the version control tool for PL/SQL. It hooks Git to the Oracle Database and enables you to manage your PL/SQL code base easily. Below is a 30 minute demo video which explains the benefits of Gitora and how it works.
It’s been a little over three months since we released Gitora 2.0 and the first success stories have already started to surface. Here is one of them:
Rhenus Logistics, the leading logistics company from Germany uses Gitora to manage their Oracle Database.
Rhenus IT uses both Java and PL/SQL to serve their users and customers. They have a team of about 10 PL/SQL developers. The team manages more than 20,000 database packages, views, functions, procedures, object types and triggers spread over 30+ database schemas.
Rhenus IT wanted to move to a continuous delivery environment in which they can be more agile and deliver solutions to the business faster. Managing the PL/SQL code was the hardest piece of the puzzle.
After experimenting with other solutions in the market, Rhenus decided to move forward with Gitora.
Gitora enabled Rhenus Developers to:
Michiel Arentsen, the System Architect at Rhenus who implemented the solution at Rhenus has started an excellent blog in which he writes about his Gitora implementation. We highly recommend you to check it out. Below are the list of blog posts he wrote which should be very useful to anyone who is currently implementing Gitora at his/her company:
Using Gitora in PL/SQL Developer dual or multi session mode
Automatically log in to Gitora when connecting to Oracle
A fast way to load your database objects to a Gitora repository
We are happy to announce that Gitora 2.1 is available for download. Along with a few bug fixes, Gitora 2.1 enables PL/SQL developers to use Git Tags to label any commit point in the Git repository.
Tags can be used for a variety of use cases but the most common one is to label a Commit ID for specific versions of the code base such as tagging a specific commit with the label “Version 2.0”.
It is very easy to create tags in Gitora. Simply, go to the local commands menu, select “Create Tag” menu item under “Tags”.
A dialog shows up.
Enter the name of your tag (no spaces). Enter the commit ID you’d like to attach it to. If you’d like to attach your tag to the HEAD i.e. the most recent commit in the current branch, leave the Commit ID field empty. You may also use a branch name instead of an actual Commit ID.
Click OK to create the tag. If the tag is attached to a commit visible in the Gitora repository browser, it will show up in the Gitora Application.
To delete a tag, select the Delete a Tag menu item under the Tags menu, enter the name of the Tag you’d like to delete and click OK.
Tags are available in Gitora 2.1 Professional Edition. Enjoy! 🙂
Kind Regards,
The Gitora Team
We hosted a webinar about Gitora last week. It received more than 400 signups and over 120 people have attended the event. The interest to the webinar was so high that we hit the 100 attendee limit of the webinar software we are using. Thanks to everyone who attended and helped us to do a better webinar with their questions and comments.
If you could not make it to the webinar, you can watch it or view the slides below. The webinar consists of two parts. In the first part, we talk about transition strategies to move an organization from manual version control for PL/SQL to version control with Gitora. In the second part, we showed the capabilities of Gitora with a live demo.
OK, so you read the web site, downloaded Gitora, installed it successfully, created a few test repositories, added a few packages, issued a few Git commands from the Gitora UI. And it all works fine. But now what? How do you actually start using Gitora in your development life cycle? How can you actually benefit from it?
In order to show you how you can use Gitora in your daily work we are hosting a free webinar on November 22nd. You can register at: http://www.prohuddle.com/webinars/Gitora/Version_Control_for_PLSQL_Developers.php
During the webinar we will cover the following topics with a live demo:
The webinar is free but space is limited. Sign up today.
Kind Regards,
Yalim Gerger
Founder