![]() Jython API – This is a server side scripting interface so this is definitely the fastest out of three in terms of execution, but it runs on the server itself so it can’t connect to different servers. ![]() You require knowledge about basic usage on how to call REST Services in general It however becomes very tedious since if you are trying to do complex work, you would also have to deal with conversion of xml request/response. ![]() REST API – This is the easiest interface to work with since its a standard and you can make direct calls through command line tools to connect to any target XLD Server. You can connect to any server as long you can access the server and you have login permissions(in security). Objects returned from the server are converted to convenient python objects to work with simple python constructs You require knowledge of python to work your way with CLI. You can connect to any server as long you can access the server and you have login permissions(in security). Infrastructure (Existing ) Name: Infrastructure/windowsĬLI Scripting – It uses a custom java library and jython to interact with a target XLDeploy server. Infrastructure (Existing ) Name: Infrastructure/windows/server1 Our use case is to create an environment and add the infrastructure to that environmentĮnvironment(to be created) Id : Environments/myEnv We can talk further about each one can be used USE CASE It would give you a fine comparison of how to do the same thing using different approaches. How about we do a comparison of Jython API vs REST API vs CLI tool. Now if you want to go further, it has the REST API and last but not least, the latest addition of the Jython APIs (Server side scripting) that can be used for XL-Rules and for creation of custom REST Endpoints. There is the GUI interface and then there’s CLI(Command Line Interface). In Deployit, we defined the two target environments, containing the appserver and databases as well as a remote test host for post-deployment smoke tests.I bet all those of you working on XL Deploy for a while might feel overwhelmed by all those different ways you can interact with the server. We then proceeded to demonstrate a continuous deployment setup along these lines for two variants of the chess application:Ī MySQL version (chess: source code on GitHub ) to a JBoss & MySQL setupĪ MongoDB version (mongochess: source code on GitHub ) to a Tomcat & MongoDB setupįor the actual deployment of the application we used Deployit, XebiaLabs' enterprise application release automation product. What happens when a pipeline stage fails? What triggers for/checkpoints between pipeline stages do I need?Ĭan I automate triggering/checkpoint validation? What needs to be in our deployment packages?Ĭan we retrieve these components automatically?Ĭan we deploy the same components to all environments, automatically?Ĭan we keep environment information out of our builds? We also introduced a set of questions that can serve as a useful "self-assessment" to give you insight into the progress of your preparations: configuration resources etc.)ĭefine automatable release triggers & checkpoints You can see the recording here, but he kindly provided this detailed write-up on the demo flow - many thanks, Andrew!Īfter demonstrating the Jenkins Enterprise CI setup, we discussed key preparation steps for expanding to continuous delivery (see the following blog post for more details on this topic):ĭefine initial pipeline scope and future expansion planĬollect all application components (incl. On Wednesday, Andrew Phillips of XebiaLabs and I hosted a very successful webinar ( Jumping from Continuous Integration to Continuous Deployment with Jenkins Enterprise and Deployit ): Andrew is VP of Product Management at XebiaLabs and on the webinar he did a great demo of how to use the Jenkins Deployit Plugin to manage complex, multi-platform deployments.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |