Overview
As a database script developer, once you have reached a stable state with your .sql scripts, you will check them in your company Source Code Management system (SCM) like TFS, SVN, Git Stash, BitBucket, ...
Once those scripts are checked in the SCM, a job to package them and deploy them in the REF Database will be started automatically (CI) or manually.
As part of this job the following actions will happen:
- Checkout the SQL code from the appropriate branch
- Checkout the DaticalDB project from the main branch
- Run the deployer through the Command Line Interface (CLI) "hammer groovy deployPackager.groovy", this will includes:
- Create an artifact ( comprised of the DaticalDB project directory)
- After the artifact has been created, the process will be the same in each environment:
- download the artifact
- run the CLI to do a forecast
- run the CLI to execute the deployment itself
Checking your code into SCM
File structure
The file structure is typically as follow:
where:
- portal_sql is the name of your repository,
- sql_code is the name of the directory where the packager will look for new/modified .sql files to package, this directory is reference in the deployPackager.properties in your DaticalDB project
- the sub-directories represent the different kinds of SQL scripts to package. The process order for a commit is the following: ddl, sqlplus, sql, function, packagebody, package, procedure and finally data_dml.
metadata.properties
In each directory under the top level one (sql_code in this example), you can create configuration file named metadata, where you can pass some additional directives to the packager (like additional label or context).
Git
For a complete understanding of Git please refer to the official documentation.
- Get the latest version for the code
- "git clone" (the first time)
- or "git pull" if your local repository already exist
- change to the correct branch
- "git checkout branch_name"
- create files in the correct subdirectories (you may have to create the subdirectory first) as required
- add the files to your upcoming commit with: "git add <filename> ..." or "git add ." to commit the whole current directory and its children.
- Commit the files you have added with :
git commit -m "Commit message"
if the commit message contains some text between square bracket like "Create employee table [JIRA-1234]", a "label" will be automatically created by DaticalDB during the deployer phase. This allows you to add additional label for specific jira, feature, story, ... for a more granular deployment process - if you need to insert some kind of orders to process you files (i.e. CREATE the table before the ALTER statement), you can split you git add and git commit as in
- git add createEmployeeTable.sql
- git commit -m "Create employee table"
- git add AlterEmployeeTable.sql
- git commit -m "Add a column to the employee table [JIRA-2345]"
- Push your changes to the git server so the packager (and your colleagues) can have access to the changes:
- git push
TFS
Build Systems
You will find below more specific instructions on how to setup your packager job in each major build system, if yours is not explicitely explained below, feel free to use those instructions to create your own process or contact us to get some help from a team of seasoned professionals.
Jenkins
Those instructions are based on GitHub.com server and a Linux environment.
We use the 2017-july branch for the SQL repo
Source Code Management
We usually set up our build to be a multiple SCMs one. TO avoid to have to deal with passwords (you need to be sure you will not be queried for password or it will hung the job), we simply use the SSK key mechanism provided by GitHub.
We also use 2 additional behaviors for that step:
- check out to a sub-directory: portal_sql
- Check out to specific local branch: 2017-2017
That step should look like:
