I would like to migrate applications from udeploy tool to xldeploy for deploying into lower environments, will it be possible?
Technically yes. But it will require some work to setup your package (like defining a deployit-manifest.xml) and configuring XL Deploy to connect with your infrastructure.
So there's no automated conversion between udeploy and XL Deploy.
Related
Looking at Microsoft documentation that says, under "Multiple deployment environments (production and staging)", that the "Service Fabric allows you to have multiple environments for your apps or to deploy different versions of your app side-by-side." How is this done and what does the topology look like? At any point in the cycle would different VMs in the cluster be at different versions or would different versions be installed on the same VMs? Particularly interested in Dev/Test/Prod environments, not simply upgrading Prod through a staging mechanism, though that would be good to better understand as well. Thanks.
I'm a Ruby developer, but I like Scala very much as well.
For Rails framework we have awesome tools that supports deployments like Capistrano automation tool and Puma/Unicorn servers. With simple cookbooks using Chef or Ansible I can easily setup my VPS and deploy Rails application there.
How does automatic deployment look like in Play framework? What is minimal required stack for developing and deploying Play applications? Are there any tools for automatic deployment? What are recommended application servers?
All you need to run a Play app is a JVM. Play is container-less. So deploying your Play app in production is as simple as running a script that invokes a fat jar with all the other required jars in the classpath.
$play dist should generate a zip file that contains everything you need to run the app.
You can use Ansbile to automate.
http://code.hootsuite.com/automating-our-scala-deploys-with-ansible-case-study/
http://www.ansible.com/press-release/ansibleworks-typesafe
To deploy Play Framework apps in AWS (Amazon) ec2 using Ansible playbook
As well as Chef.
https://github.com/gildegoma/chef-typesafe-stack
If you are happy to run on AWS, Boxfuse comes with native Play 2 support.
You can now simply execute boxfuse run my-play-app-1.0.zip -env=prod and this will automatically:
create a minimal AMI tailor-made for your Play 2 app
create an elastic IP
create a security group with the correct permissions
launch an instance of your app
All future updates are performed as blue/green deployments with zero downtime.
This also works with Elastic Load Balancers and Auto-Scaling Groups and the Boxfuse free tier is designed to fit the AWS free tier.
You can read more about it here: https://boxfuse.com/blog/playframework-aws
Disclaimer: I'm the founder and CEO of Boxfuse
I'm trying to learn about Heroku's deployment capabilities. I've used Google App Engine in the past and have found its support for multiple simultaneously-accessible live application versions useful, for example, in order to test a new version in the production context before making it the default, running a specially-instrumented version in parallel with the default version to debug a problem specific to the production environment (e.g. production data), for A/B testing, traffic splitting, gradual rollout, etc.
Does Heroku have support for this kind of thing? My Googling has not turned up anything.
No, it doesn't offer support for this right now.
I'm using Fedora and I deploy Symfony projects in my local machine using virtual hosts. How can I deploy my projects in server to public which others can view it through their machines?
Thanx...
You have several way to deploy you symfony project. I will avoid ftp, svn up on prod, etc .. So, here is 2 good ways.
The built-in deploy task
Symfony comes with a built-in depoy task that has been used when symfony 1.4 was released. I think it's less and less used now (because there is better tool).
The simplest way to deploy your website is to use the built-in project:deploy task. It uses SSH and rsync to connect and transfer the files from one computer to another one.
Using capifony, which use Capistrano
Capistrano is an open source tool for running scripts on multiple servers. It’s primary use is for easily deploying applications.
capifony is a deployment recipes collection that works with both symfony and Symfony2 applications.
This way is far better than the previous one because you can automate many script when deploying (like testing your code, start a fresh built lib, upgrade database, share config file). But the most important one (from my POV) is that you can easily rollback a bad deployement. It's damm easy.
I am setting up an automated deployment environment for a number of decoupled services that are in active development. While I am comfortable with the automated deployment/configuration management aspect, I am looking for strategies on how best to structure the deployment environment to make things a bit easier for developers. Some things to take into consideration:
Developers are generally building web applications, web services, and daemons -- all of which talk to one another over HTTP, sockets, etc.
The developers may not have all running on their locally machine, but still need to be able to quickly do end to end testing by pointing their machine at the environment
My biggest concern with continuous deployment is that we have a large team and I do not want to constantly be restarting services while developers working locally against those remote servers. On the flip side, delaying deployments to this development environment makes integration testing much more difficult.
Can you recommend a strategy that you have used in this situation in the past that was worked well?
Continuous integration doesn't have to mean continuous deployment. You can compile/unit test/etc the code "continuously" thoughout the day without deploying it and only deploy at night. This is often a good idea anyway - to deploy at night or on demand - since people may be integration testing during the day and wouldn't want the codebase to change out from under them.
Consider, how much of the software can developers test locally? If a lot, they shouldn't need the environment constantly. If not a lot, it would be good to set up mocks/stubs so much more can be tested on a local server. Then the deployed environment is only needed for true integration testing and doesn't need to be update constantly throughout the day.
I'd suggest setting up a CI server (Hudson?) and use this to control all deployments to both your QA and production servers. This forces you to automate all aspects of deployment and ensures that the are no ad-hoc restarts of the system by developers.
I'd further suggest that you consider publishing your build output to a repository manager like Nexus , Artifactory or Archiva. In that way deployment scripts could retrieve any version of a previous build. The use of a repository manager would enable your QA team to certify a release prior to it's deployment onto production.
Finally, consider one of the emerging deployment automation tools. Tools like chef, puppet, ControlTier can be used to further version control the configuration of your infrastructure.
I agree with Mark's suggestion in using Hudson for build automation. We have seem successful continuous deployment projects that use Nolio ASAP (http://www.noliosoft.com) to automatically deploy the application once the build is ready. As stated, chef, puppet and the like are good for middle-ware installations and configurations, but when you need to continuously release the new application versions, a platform such as Nolio ASAP, that is application centric, is better suited.
You should have the best IT operation folks create and approve the application release processes, and then provide an interface for the developers to run these processes on approved environments.