Amis conference soa deployment. the dirty tricks using bamboo, nexus and xl deploy

Editor's Notes

• #11: This is a familiar image to MN
• #14: This is a familiar image to MN
• #15: Tip: Configuration (e.g. datasources, JMS) should not be part of a service functional unit since there is only a single version of configuration per release. Determining the configuration per release is more difficult as it is spread out over services Tip: Less types of deployables makes it easier for everyone Pom -> DAR
• #21: Changes in artifact structure are troublesome. 12.2.1 libraries not yet in Oracle Maven public repository. OSB 12.2.1 and Maven is troublesome
• #29: Usually we show up with a new tool for an existing legacy solution otherwise it would be much easier. What we can see here? Developer teams committing their code to the version control, testing and integration runs properly the agile way. The build process is able to generate the releases. On the other side, operations team work with a combination of manual steps, cloned artifacts, configuration and deployment scripts. The build process in Bamboo provides the Nexus repository with most of the artifacts but the deployment process is using other location to pick them up.
• #30: The desired result of automation looks like this. Nexus is the single repository for all deployables and their dependencies We get rid of all kind of copying through the chain Any kind of formerly manual or losely scripted action gets integrated into the XL Deploy tool. This goal may lead to unrealistic expectations. Like deployment team believes they push one button and after 2 hours they see Done.
• #31: XL Deploy is an agentless application release automation tool across all platforms. It is running as a Java process Operates with a JCR repository and LDAP security Interacts with its destinations through technology plugins, which are loaded at startup CORE Integrates with plugins Unified Deployment Engine determines deployment requirements Storage and retrieval of deployment packages Executes deployment plans Security Reporting PLUGIN Interaction to a middleware Extendable Core requests, plugin replies All loaded at startup Licensed plugins: come with the installation, supported Community plugins: open source (GitHub), not supported
• #32: The fundamental layer of the user interface is the REST API. Depending on the security requirements it is accessed via http or https. It uses basic authentication and exposing pre-defined service objects for the different phases of the deployment process. For instance server, user and control for maintenance, monitoring and security management, repository to maintain the CI-s and deployment and task to create plans and interact with the deployment process. The other 2 interfaces are built upon this REST API. Command Line Interface is a separate installation of Jython libraries for remote communication with the XLD server. The Graphical Interface is a browser client works with Flash plugin. It visualizes most of the exposed services, furthermore, plugins can also expose their functionality using Java annotations
• #33: Package: A version of an application Deployables: Configuration Items (CIs) that can be deployed: Artifact: Physical file in the repository Resource: Created on the target platform e.g. JMS queue/topic, DSource, CF Containers: Deployment targets Domain, server, cluster, DB client, Local, SSH, CIFS Dictionary: Collection of placeholders and their values Environment: Collection of references to infrastructure CI-s (members) Blue: CREATE Grey: NOOP Green: MODIFY Red: DESTROY
• #34: Let's see how we feed the XL Deploy repository. In the Maven project we define the resources with their properties and when applicable, the deployable artifact in the form of standard dependency (groupId, artifactId, version, type and optional classifier). The XL Deploy plugin wraps the resource list with the package definition forming the manifest file, downloads the dependency artifacts from the Nexus repository and packs them all together into a DAR file.
• #35: Here is an example how the basic Oracle SOA plugin treats its artifacts. This plugin is in practice a derivation from WebLogic plugin. It uses new artifact types, enriched with properties that SOA Suite deployment requires. The target containers, however, are of the same types as for the WebLogic deployments. How to prevent the mapper to spread the composite all over other non-SOA clusters? For example with tagging.
• #36: Here is an example of the combination of plugin type system and the tagging feature. The SOA Suite plugin extends the WebLogic plugin with the artifact types soa.DbConnectionFactory and soa.Composite and associates them to the container wls.Cluster. Since the container type may represent other weblogic cluster as well, we have to reduce the candidates to our SOA domain. We stick a label to each artifact and put both labels on the tag list of the cluster.
• #37: As we saw, the XLD environment is a collection of references to potential physical containers and placeholder dictionaries. The deployment process this way can in the deployed artifact combine the properties of the deployable, the replaced values using the dictionaries but also attributes of its actual container.
• #38: The deployment process in time is a good co-operation between the core process and the plugins. The plugins determine the source and the destination through their types and the tags Delta analysis: Important to note, current state of middleware virtual image in XL Deploy! Orchestrators: by container, by deployment group, sequencing by dependency
• #39: Each deployment action starts with the selection of a deployment package and its destination from the environments. If no version of the same application is deployed there, the engine recognizes it as an initial deployment otherwise as an update. In this example the package contains a SOA composite only. The review shows us all steps generated by the plugin. Reviewing the main deployment step we can see several contributors to the final plan. The order of the execution within the plan is configurable, the name of the actual rule (rules can be added, disabled and customized) and the script (in this case meant for WLST) template from the SOA plugin being applied on the target. The actual result is however a wrapped script containing initializations and supporting functions from another plugin for python.
• #40: Vervolgens 2 voorbeelden
• #41: The all-in archive of a service is replaced by the elementary units The environment specific parts (config and customization) are replaced by their placeholdered templates The scripted objects are replaced by manifest items without file artifacts
• #42: At the customer we confronted with complex database script structures surrounded with a logging mechanism within the database. Keep the encapsulated object Trust all internal orchestration to the deployable (=developers)
• #43: Considering rollback scenarios is one of the critical points of deployment. Simple files or folders are usually easy decision. We can test it out very well what to do to recover after deleting or overwriting too much. Not necessarily a rollback, more to keep data integrity. Assuming an update when we create a new database table and filling it up with critical data or new column with constraints etc. After some runtime we downgrade the containing release but a rollback would not succeed or would cause inconsistency. Automating an initial restore point and reverting to it at the end may help.
• #44: The last example is related to the efficient encapsulation of a legacy process. The deployable objects are structured folder with configuration scripts and the property lists. The same scripts take care of configuration before and after a SOA-OSB service deployment, determined with different arguments PRE and POST. For delivery reasons, the configuration script got its own package. According to the previously discussed topics, the legacy object is already prepared with placeholders and tags. The standard plugin would just extract the folder to the target host with one step and that's it. To organize the proper sequence, we can define a new rule and associate to our artifact. The new rule will surround the extraction with 3 extra steps: 1. Execute the main script with PRE 2. Suspend the plan 3. Execute the main script with POST Between 2 and 3 we execute the SOA-OSB deployment task. Then we resume the waiting task.