FlexDeploy doesn’t have an official Siebel plugin, but don’t let that stop you from using FlexDeploy to automate your migrations. FlexDeploy can provide a lot of value to the process. Let’s take a look at the process improvements and benefits related to:
- Automation
- Security
- Scheduling
- Approvals
- Visibility and Auditing
If you haven’t already, you should be applying DevOps principles to Siebel. For instance, you can write scripts to migrate your repository. FlexDeploy can execute those scripts, and provide visibility into their operation.
You can also improve the security for the passwords that are typically stored in the shell files, or shown to users who have access to run ps on the server. The alternative is called property replacement and can be easily configured within FlexDeploy. To securely store your passwords and prevent them from being printed in plain text, all you need to do is check the existing script into your Source Control Management system after replacing the Siebel password with a FlexDeploy property.
For example:
DATE=`date +%Y%m%d`
export SBL_ROOT=/u01/Siebel/ses/siebsrvr
${SBL_ROOT}/bin/repimexp /a E /G ALL /u SADMIN /p passwordIsHereInPlainText /c SBA_SBL_DSN /d SIEBEL /r ‘Siebel Repository’ /f /u01/Backups/SiebelRepository.dat /l /u01/Backups/SiebelRepoExport${DATE}.log
you then alter the code to be:
DATE=`date +%Y%m%d`
export SBL_ROOT=/u01/Siebel/ses/siebsrvr
${SBL_ROOT}/bin/repimexp /a E /G ALL /u SADMIN /p ${{SIEBEL_PASSWORD}} /c SBA_SBL_DSN /d SIEBEL /r ‘Siebel Repository’ /f ${{FD_TEMP_DIR}}/SiebelRepository.dat /l ${{FD_TEMP_DIR}}/SiebelRepoExport${DATE}.log
Then, in FlexDeploy, you securely store the SIEBEL_PASSWORD value. Now it isn’t in the file, and it won’t show up in the logs. Further, the next time that the password is changed, you don’t have to hunt through all the scripts to replace the password, as the password is now stored only in FlexDeploy. An API to update the password through REST is provided.
But, password security isn’t the only benefit that you gained. Now there is a UI for scheduling and approving builds and deploys. There is a clear audit trail of which date’s export has been imported last into each environment. Multiple shell steps, file copy steps, or any other plugin operation can be grouped together, so you can force your Siebel migration to happen before or after other dependent steps. You can also eliminate the risk of deploying incorrect versions of code to upper level environments using the approvals, windows, FlexFields, and other controls that FlexDeploy provides. The Siebel IT lead could even take a vacation now and rest assured that business users won’t need his or her intervention to continue their day to day repository migrations.
The recent release of FlexDeploy 4.5.1 brings some new plugin operations to the table as well. The Partial Deploy File Build and Deploy operations allow developers to group files that are in SCM into packages for deployment using a great UI, just checking the files that should be included.. These packages can then be deployed to different environments with auditing, controls, and automation. The packages can be modified a few times during development, tested in a CI environment, and then migrated to the production environment with the repository at the right time.
It’s not hard to see the ease of use for developers, team leads, and management. As a united team, code can be moved across environments predictably and with visibility and control. Your environments will be more secure, more predictable, and your IT team will have more time to write new code as they will be able to allow most migration tasks to take care of themselves.
