I have an application that was pushed to the Liberty runtime via the packaged server deployment method. In the future, if I make changes to my code without having to change my server.xml, do I still have to build a package and deploy the same way? Or can I just Commit and Push my changes from Eclipse or DevOps straight into Bluemix?
you still have to push your application using the packaged server deployment method, because even if the push action uploads only what needs to be updated, it makes a full restaging once the upload is completed.
By this way, if you push only your application files without using the packaged server deployment method, it will use its server.xml template overwriting all your previous customizations.
If you are using IBM Eclipse Tools for Bluemix you can take advantage of incremental publishing support by putting your packaged server in development mode. Right click on your packaged server and select Enable Development Mode. Once enabled, you can make changes to applications that are deployed on the packaged server and then once you are finished with the changes, right click on the Bluemix server and select Publish. No re-push is required and only changed files will be copied over to the Bluemix server saving a lot of time. See the following for more details: http://www-01.ibm.com/support/knowledgecenter/SS8PJ7_9.5.0/com.ibm.etools.iwd.doc/topics/tincrementalpublish.html. As you mentioned, if you change the server configuration (server.xml) then you will need to re-push the packaged server. Incremental publishing is supported for applications deployed directly to Liberty on Bluemix as well.
Related
I had deployed the app last on friday and it got deployed successfully.But since, today morning the deployment is not happening at all.It is checking for conflicting process and failing.
I'm doing this from the webide and i'm not able to check what are the conflicting process and how to resolve it.
WebIDE lacks the ability to do proper investigation on deploying apps to SAP Cloud Foundry.
The best way to do this is to install the Cloud Foundry Multi-apps plugin (see this tutorial). This will allow you to use the local terminal to control the deployment (or alternatively use SAP Business Application Studio which already has the commands built in).
Then use the command cf mta-ops to get the list of ongoing operations and cf dmol <operation_id> to download the logs for that operation. cf deploy can be used to abort/retry operations.
I'm starting out with IBM Bluemix and CloudFoundry. Using the tutorial examples of the Node.js/Cloudant app I have a dev workflow that seems really slow. What is the best practice for development with cf?
Here's what I do now
Edit my files locally
cf push myapp
Wait for a long time for the app to deploy
Test and find an error
Repeat
If you are building a Node.js application, you can use Bluemix Live Sync to quickly update the application instance on Bluemix and develop as you would on the desktop without redeploying.
You can choose to download the bl cli to sync with a local directory using Desktop Sync, or set up your project on DevOps Services and edit the code directly in your browser using Live Edit. Look in the documentation for Bluemix Live Sync.
https://developer.ibm.com/devops-services/2015/02/13/everything-kitchen-sync-bluemix-live-sync/
If you are doing more intensive development, it would be faster for you to set up node locally and push to Bluemix periodically. You can still consume most Bluemix services locally.
If you have to rely on an architecture resident in Bluemix and you do not have the possibility to test on local you cannot avoid the "push" command and the workflow you described. Regarding point 3, you might have incurred in a platform issue announced at https://developer.ibm.com/bluemix/support/#status.
I have an application that was pushed to the Liberty runtime via the packaged server deployment method and I understand that some of the default features provided by Liberty will change in one of the upcoming buildpack updates. Will this change in default features provided adversely affect my packaged server deployment?
If you're deploying/restaging your application in a manner other than a packaged server or a server directory, then the change in the default feature set might affect your application. This is due to the changes in spec levels in the new default feature sets. However, if you used the "packaged server" or the server directory method for deploying your app then you will not be affected. This is because the features you put in your server.xml will still get picked up due to the fact that the buildpack will provide Java 6 & 7 features.
If you need more information about the new default features added to the buildpack, how to make your app resilient to the changes, and even how to "preview" the new buildpack for testing purposes, see the link below:
https://developer.ibm.com/bluemix/2015/09/08/upcoming-liberty-for-java-buildpack-changes/
currently I am working with mule esb in cloud, to achieve this I am using free trial version of Cloudhub. FYI, I am new to cloudhub and right now tring to deploy my mule application there. Unfortunately, everytime I tried to deploy my application, it can not be deployed.
I have tried 2 ways to deploy the apps.
The first one is from the Mule Studio, by following this documentation:
Deploy Apps to Cloudhub From Mule Studio
When I tried that way, I got following error:
I guess it was because of the proxy.
The second way I tried is by deploying it directly from the cloudhub.io, by following this documentation:
Deploying Apps Directly From Cloudhub.io
But, when I check on the deployment section, I found out, that my application is not uploaded. Then I tried to upload it again, update it, and run the application, but it seems that the application still not uploaded and the change I made is not applied.
Here is the error I got:
FYI, before I upload the application to cloudhub, I compressed the application folder into zip file.
How can I solved this problem? Do you think I did something wrong when deploying it? Thanks in advance.
I too faced similar problem, when deploying application in cloud hub, using Mule 3.5. My application inserts Contacts info (FirstName, LastName, Title, Email etc) from CSV file in Salesforce "Contacts" object. With proxy details configured, my application was running fine in local machine but when deployed in cloud hub, I was getting "Unknown host Exception. Root exception in proxy (something similar to this) " exception.
What I did:
I have removed proxy details from Salesforce connector and re-compiled and deployed in cloud hub. When I tested, the contacts from csv file are getting inserted in Salesforce "Contacts" objects.
Note: When Proxy details are removed, it works in cloud hub but fails in local. It seems cloud hub takes care of proxy connection and we don't need to explicitly mention it.
Regards
Ravi Nori
Be sure that you configure your http endpoint like this:
<http:inbound-endpoint host="localhost" port="${http.port}".... />
CloudHub will automatically expand http.port property to the correct value.
To make it work deploying from CloudHub you shouldn't compress your project yourself and upload but make Studio create a deployable archive: Right click on your project and then click export, select 'Anypoint Studio Project to Mule Deployable Archive' under Mule category. That will have Mule ESB application structure and should work in CloudHub.
Check your http global endpoint is like that
or you can give in properties file like http.host=0.0.0.0 http.port=8081
these values you can give directly in cloudhub properties.
From flow you can access like ${http.host} , ${http.port}
First check that domain name is available
How do you handle the deployment of a LightSwitch application into a production environment?
i.e. the LS application has been developed, but it now needs to be installed first into Test, and then into Live.
We don't want to use the "manual" approach, i.e. use the Visual Studio Build / Publish option, rather we want to automate the deployment.
My feeling is that deployment is one of the real weak points of LightSwitch. If you are using the very simple deployment model that is build into the product, and you're doing everything within a Windows domain, the publishing wizard can do everything. But if you're deviating from the model at all LightSwitch will fight you. I'd really like to see an "advanced" deployment option that provided some configurability.
Here's how I solved the problem you're having with LightSwitch applications that are targeting web deployment:
At the beginning of the project, deploy once to each target environment using the publish wizard. This is the easiest way to get the database set up.
As new builds are deployed, use the publish wizard to deploy to a deployment package to a standard location on the local development machine.
The deployment package is just a zip file, so you can open it an drill down to where the actual binary release is. I use a powershell script to copy the binary files out of the the deployment package and in to a local SVN working directory. Note that you must not copy web.config file during this step.
Check the unpacked binary files into SVN and use SVN to manage the deployment.
Manage schema changes with SQL scripts.