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.