This document will walk you through the steps to complete a deployment request.
Deployment Process in a nutshell
Within Falcon Deploy, users with different roles, working on a particular project are organized into teams. In our example, the teams are HR, Mart and Finance. Each project/team has a dedicated application repository. The users are given roles which are in essence a collection of repository privileges. These roles may be granted to a team as a whole. Users inherit the permissions granted to the team. Users then add SQL script files into the repository which are meant to be deployed to the database targets. We then link the repository to the respective databases via mappings. A mapping contains one repository and one or more database targets. Users can now create deployment requests. Upon request creation, Falcon Deploy facilitates the deployment of SQL scripts from the repository to the mapped database targets across environments.
You will need to configure a Mapping between an Application (repository) and its intended Database targets.
If you are not an administrator, you will also require database credentials and Deploy Privilege on the target database. If you do not have the credential and privilege you can still raise a request and the administrators will be notified to complete the request.
Creating a Deployment Request
Begin by selecting the New Deployment button located on the right side of the top navigation bar. This step launches the deployment wizard.
Click on the drop-down to select the application (repository) for this deployment.
Here you can enter the application name to search and select, or you can use the drop-down to scroll through the list and select the application.
Click Next on the upper right corner of the wizard.
Here you will select the SQL files from the repository that has to be deployed. You can do this in two ways. The Select Box works great for a small number of scripts especially when you do not remember the file names. You can use this option to scroll or type and search for a SQL file by name. The Text Box works best when you need to input a large number of SQL files to deploy. We discuss both options below.
Note: You need to have the SQL files in the repository before starting a deployment.
Select the SQL scripts from the left pane in the window. You can double click on the file or use the right arrow button in the center to select the SQL files for deployment.
Press the Validate selected scripts button. At this point, Falcon Deploy will validate the files. If a file validation fails, the application will not let you proceed.
Example: Falcon Deploy adds the SPOOL statement automatically before starting a deployment. So, if you have a
SPOOL command, the validation will fail. Another example is the
ACCEPT sqlplus commands. These commands are currently not supported since they require user intervention. As a workaround, Falcon Deploy has functionalities to pass values as parameters to SQL files during deployment. We discuss this in a subsequent section.
If you have a large number of scripts to deploy, you can use the Text Box option to bulk-paste a list of SQL script file names. Press Validate.
When selected files pass validation, the Next button is highlighted. Hit Next to proceed.
This section lists all available databases configured in the mapping for the selected application.
Choose the database targets to which the SQL files selected in the previous step will be deployed. The names in the list are alias names for a TNS connection endpoint consisting of protocol, hostname, port, SID or Service name. Please refer to user guide for configuring database targets.
For each database selected, we get the following controls.
This allows you to dictate the order of deployment in a multi-target deployment request. A value of 1 has the highest priority and will be deployed first. Choosing the priority gives you the control and flexibility to prioritize the order of the deployment.
Serial deployments ‐ If you have more than one database target to deploy, and you want each database deployment to be done one after another, choose different priorities for the database targets.
Example: If you want to deploy to development first and then to a QA environment, choose priority 1 for development and 2 for QA.
Parallel deployments ‐ If you have more than one target to deploy and you want the deployments done in parallel, choose the same priority for all database targets.
Example: Choosing priority 1 for both development and QA will launch both database deployments at the same time.
To deploy to a target, you need to have Deploy Privilege and credentials for the database target. If you don’t, you can still raise the request according to your requirement and select Notify Administrators to request the administrators to complete the deployment for you.
Upon submission, administrators get notified of your request, and they will be able to complete the deployment request.
Post Deployment Wrapper
Selecting this option will run a wrapper script (if configured) at the end of the deployment. These scripts usually take care of routine tasks such as compiling invalid objects or granting privileges. You may or may not need one depending on how you manage your database environments. Treat this as a hook to a configured script that gets called every time you need one.
Here you will input the database credentials used for connecting to the database to do the deployment.
Enter Credential ‐ Use this option to input the username and password. Use the Validate button to verify the credential and connectivity to the database. After validating the credential, you can choose to save the credential for future use. The credentials are encrypted and saved in the database.
Saved Credential ‐ If you have a saved credential, you can select that from the list.
Delegated Credential ‐ Any database user that has the required privileges on the target schema can be used for deployments. Usually, the schema owner login or a privileged user login is used. In many environments, developers or analysts do not have access to these logins due to obvious reasons. It is an industry practice for increased security, data protection and also to reduce issues due to human errors. So, developers depend on DBAs to get a change rolled out to the database. This dependency alone could slow down development in some cases.
We understand that securing privileged user account, or schema owner account is needed. What if we can allow developers to deploy to development databases using a particular database user account without exposing the credentials? This change would allow for faster development and testing iterations. This also frees up the DBAs from repeated deployments during the development and testing phase. It is a debatable approach, and it depends on individual teams.
Should you decide and desire to allow developers to deploy at will to non-production databases without exposing the database credentials, Falcon Deploy can handle this requirement. It is accomplished by using a Delegated Credential. An administrator can delegate a Saved Credential to users. This credential is then automatically available to users during deployment. A developer can use this delegated credential from the drop down and deploy using that credential. Note that all deployments are logged automatically. So, changes going into a database system can be tracked with complete details.
Only users who have been granted the delegated credential can use it. Please note, the user also needs the Deploy Privilege to be able to deploy to a target.
If you are deploying to multiple targets and do not want specific scripts deployed to a particular database, you can use the DELETE option to remove the SQL script for that target.
Use the icon to drag and rearrange the order of scripts for deployment.
Name of the SQL file being deployed.
Use this option to change the database credential for a particular script.
This option enables you to use different database credentials within the same deployment.
Use this field to pass parameters to a script that has substitution variables. We pass the values as submitted.
The option you choose here dictates the deployment workflow and the script’s deployment status when the script encounters a database error.
Exit on Error ‐ This is the default.
If a step encounters a database error, the deployment stops and exits. Subsequent steps in the same SQL script are not executed, and the process exits. The failed script’s deployment status is marked as Failed. If there are any scripts after the failed script in the deployment, they are not deployed. At this point, user intervention is required. There are options in the REQUEST page that allows you to continue or abort.
If no database errors are encountered, the script’s deployment status is marked as Successful. Deployment continues if more SQL scripts exist.
Continue on Error
Choose this option if you want the SQL script to continue on database error. Upon error or a clean execution, the script’s deployment status is marked as Needs Verification. You can review the execution logs and optionally change the script’s deployment status.
Schedule and Notification
Scheduling is done at a request level. A request can have one or more deployments. Each deployment is for a particular database target. So, you can create a single request with a set of scripts and deploy it to one or more database targets. If deployments to your database targets have to be done at different times, create separate requests.
- Once, Immediately ‐ The deployment begins immediately.
- Once, Later ‐ Schedule for a future date and time.
Despite scheduling, there may be times when the deployment does not start. They are listed below.
- If you have not given credentials and selected ‘Notify Administrators’ when submitting the request.
- Once, Immediately ‐ The deployment does not start until the administrator enters the database credentials and submits the deployment.
- Once, Later ‐ The deployment does not start if the administrator has not provided the credentials until the scheduled start time. The deployment is abandoned in this situation. At this point, the request needs user intervention and can be managed from the REQUEST page.
- If deployment to a target needs approval.
- Once, Immediately ‐ The deployment does not start if it is waiting on approval.
- Once, Later ‐ The deployment does not start if the approver has not provided the approval until the scheduled start time. The deployment is abandoned in this situation. At this point, the request needs user intervention and can be managed from the REQUEST page.
- Deployment does not start if a higher priority deployment is still in progress. In this case, it is just waiting for the higher priority deployment to complete.
- Deployment does not start if a higher priority deployment is on hold awaiting credentials or approval or both.
E-mail notifications are generated when you submit deployment requests.
- On Success ‐ Check this box if you would like to receive an email notification when a deployment in the request has completed successfully.
- On Failure ‐ Check this box if you would like to receive an email notification when a deployment fails.
You can choose a condition, both or none. These options work at a deployment level. If the request is a multi-database deployment, you get notified for each database deployment.
Review the request and chosen options. Use the Submit button at the bottom of the page to create the request for deployment.
Upon submission, Falcon Deploy redirects you to the activity timeline page where you can see real-time execution statuses and related information.
Use the request page to manage your deployments.
Deployment logs can be found in the status column on the activity timeline and request page.