summary: Make application execution and deployment a first class citizen and concept in Gradle (smoke testing, enviroments, roll back, ...)
status: Discussions are happening and we will iteratively add features after 1.0.
code: planned
Every application is launched, or deployed, at some point in the development process, regardless of whether it is a web application, GUI application, or application for a mobile device. Often the application is deployed many times in different environments. For example, a web application may be deployed on the developer’s machine for automated functional test. It may then be deployed on a build machine during the post-checkin CI build. Subsequent CI builds may deploy the application into a QA environment, or even into a production environment.
In Ant, Maven and in today’s Gradle, deployment is just a task or goal. Instead, we want to make application execution and deployment a first class citizen and concept in Gradle. A richer model will allow Gradle to do most of the work for deployment. Gradle will understand that different deployment environments may require a slightly different artifact to be deployed. Gradle will understand how to smoke test a deployed application, and how to rollback a deployment on smoke test failure. It will provide incremental remote deployment for debugging. The Ruby tool Capistrano is one place to get inspiration from for what can be done.
-
Perhaps also Chef support for deployments? It could be as simple as modifying an artifact version in a chef recipe and a knife cookbook upload, or as involved as provisioning VMs for a smoke test.
-
-
Puppet integration...I might have to FedEx Hans and team a round of beers. Making deployment a first class citizen _and_ getting chef/puppet integration would be just fantastic.
-
-
Maybe this even could be extended to support testing locally with a virtual machine, like what Vagrant does. Cannot wait to see this implemented!
-
Loading Profile...

Twitter,
Facebook, or email.
EMPLOYEE




see the change log