commentBlock = $("#comment_post_31707").find('.comment-blocks'); commentBlock.find('.loading').hide(); commentBlock.find('.see-all-comments').hide(); commentBlock.html("
<\/a>
\"it_user561492<\/a>
it_user561492<\/a>Vice President, Sr. Architect at a financial services firm with 1,001-5,000 employees<\/span><\/div>
<\/span>Real User<\/span><\/div>
<\/i><\/div>
<\/i>Report as inappropriate<\/a><\/div><\/div><\/div>

Hi Julien ,\n
We are evaluating XLDeploy as a continuous delivery tool for a container as well as a tranditional VM platform. As part of continuous delivery we want on demand env provisioning as well. We have IaaS APIs that are offered by our platform team to provision nodes by passing the necessary CPU, Storage and memory as parameters to the API. Underneath the API our platform team uses Ansible playbooks to provision the infra resources. They also provide an API interface to describe the application domain model in terms of the configuration of the app at the app, middleware and infrastructure level and a model to also describe the env ( dev, test,Qa and prod) on which to deploy the app.<\/p>\n\n

My question is will XLDeploy work for us if we have to use our own domain model and have XLdepoy call the rest API to provision the env for the app first by requesting the node on which to deploy the container and traditional app by passing the app name and env name as parameters and then by actually calling the API that actually deploys the app using Jenkins or another deploy tool of our choice?<\/p>\n\n

Please let me know.\n
Thanks in advance for your response\n
Rajesh\n<\/p><\/div>

<\/i>Like<\/span>(0<\/span>)<\/a><\/i>Reply<\/span><\/a><\/div>
<\/div><\/div>
<\/a>
\"it_user177192<\/a>
it_user177192<\/a>Java/JEE Consultant with 51-200 employees<\/span><\/div>
<\/span>Vendor<\/span><\/div>
<\/i><\/div>
<\/i>Report as inappropriate<\/a><\/div><\/div><\/div>

Hi,<\/p>\n\n

Actually if you read some devops reference book just like Continuous Delivery they strongly suggest to use the target system native facility, which XLDeploy won\'t. On the contrary each time I used the target system native installation way (ok on Windows things get more complicated since they did not provide MSI out of the box but after several iterations) all the integration went smoothly. Native installations (RPM, DEB, ...) coupled with tools like Ansible to send the same command to dozens of target servers plus some tools like Puppet for config file templating give great results.<\/p>\n\n

Now the main problem of XLDeploy apart from that is that it tries to remain too high level with its black-box plugins, so it means that you\'ll often require to tear the tool in order to do what you need. Actually if XLDeploy were just a unified console which then delegates the installation to each OS native tools this would be much much better, so that deployments can continue without XLDeploy if necessary, and the product it there to give you a convenient supervision tool and automated installation tool. Don\'t forget that good tools will never try to lock you up in proprietary formats, on the contrary they\'ll make you feel free... so that when you try other tools you come back to the first one as it is the best.<\/p>\n\n

Rgds<\/p><\/div>