Its usage may be determined or even overruled by the rule definitionsĤ. sqlplus) same way as the plugin does, with the possibility of adding the surrounding functionality. It will be responsible for wrapping the execution of the sql scripts (e.g. Its name is adopted from the original plugin. The executorScript is an OS script template.
We add the credential fields to cover the connection partģ. The deployable artifact is derived from the deployed one so all properties are propagated back to itĢ.
#XL DEPLOYIT FREE#
That one is free of recognition properties but is still handled as a directory object and gets unpacked on the target.ġ. With the type definition we extend one level higher into the udm package, namely udm.BaseDeployableFolderArtifact. Instead, let’s define a new classifier (the “virtual” plug-in) called (as sample) legacy. Yet, it has all the properties (mandatory script and rollback recognition patterns) bothering us without those being useful (database user and password). The superclass generic.Folder would be a better choice. Doing that we would break the original plug-in. However, we must not “thin” this type itself in synthetic.xml with more relaxed script recognition patterns. Sql.SqlScripts itself is a generic.Folder subclass. A developer would probably test it tailing the log after change or start the server with command line rather than service but it is good to know about the behavior. This is only visible in the log file, so in case of a service wrapper startup mode, the service itself will run but the server will be unreacheable. Generically, if the requested container of an extension type is on a hierarchy branch different from the extended type’s container, the server refuses the whole synthetic.xml on startup and fails. The practical reason is that the database related properties (for Oracle it is schema login and SID) are available there and the artifact does not mandatorily need to carry (or placeholder) them as overhead and the mapping mechanism will automatically detect it too.įile plugin CI type file.Folder will not work as its container class (overthere.Host) is inconsistent with the sql.SqlClient container superclass generic.Container. In the other scenario, we have to consider the incoming artifact just as a generic folder, which we try to target to the plugin container with of a subtype of sql.SqlClient. The wrapping shell script can be adapted to the freemarker context and used through the rule system within an os-script type step: 4 Virtual plug-in This will be tested all over the pipeline. The two main sql scripts must be modified to use their matching subfolders for the subscripts and common for the logging scripts. One scenario is to break up this existing structure, send the process back to the design and development table to fit into the plugin requirements. In the legacy system, a shell script, settled on the actual target host, with some joined properties and environmental settings, is wrapping the whole execution with restore point, mailing and security management. Naming the scripts like this makes the database plugin completely ignore them. patch.sql: executes the create scripts in the root folder, the grant scripts in the grants folderīoth scripts applies different functionality from scripts in the logging folder. setup.sql: executes the scripts in the init folderĢ. The scripts regulate all further sequencing and logic inside.ġ. Rollback scenario is out of scope (internal policy forces the use of database restore points only): Let’s see an artifact from the legacy with quite a simple and flat structure (fictive sample). The standard plugin is described at 2 The Case Yet, there is still a very tight coupled relation between the scripts and their subordinates, name matching of subfolders and so on. The standard database plugin has well defined sql script and rollback script recognition patterns, which can all be re-defined.
#XL DEPLOYIT ARCHIVE#
What happens if a legacy deployment process is very robust, tested out and trusted by the organization? On the other hand, the artifact may not necessarily align with the requirements of the plugin distributed for its purpose.Ī good example can be an archive of database scripts with the freedom in execution order, script naming and use of subfolders. That way, the deployment process itself was still completely left over to the capabilities within the distributed plug-ins. My first article I wrote about controlling deployment sequence by artifact type extensions and modifications.
0 kommentar(er)
