A Gradle book will be incomplete, unless we talk about the deployment aspect of a software component. In my opinion, in software engineering the most logical step after build automation is deployment. Deployment itself is a different domain and this has very little to do with Gradle. But still I think it makes sense to discuss build and deployment tools together, so that the reader gets an overview of Build, Deploy, and Test workflow. In this chapter, we will discuss some basics of deployment to give a flavor of the build and deployment process. We will learn how to use tools such as Gradle, Jenkins, and Docker together to create a build, deployment, and test workflow. Before we start, we have to understand, what deployment is. Deployment is as important as the build process in the software life cycle. You can write and build great software, but unless the application is deployed, it does not produce much value. Deployment of software is not just about installing software and starting it. It varies from application to application, operating system to operating system. Some application can be deployed just by copying a JAR file to a particular location; some applications require deployment in a web container, or in external containers and so on. We can generalize the deployment process of software as follows:
- Prepare the prerequisite hardware and software environment where you want to deploy the application.
- Copy project assets on the prepared environment.
- Configure assets based on the environment.
- Prepare a life cycle of the application such as start, stop, restart, and so on.
- Do a sanity check of the application to verify its functionality.
So deployment is not just copying the assets and notifying everyone that the application is ready to use. It also involves a lot of other pre and post steps. Deployment process has also been evolved along with the development processes and is still evolving with newer technologies. There was a time when the operation team used to deploy the application manually on specified nodes, configure load balancing mechanism and routing from box to box to effectively handle client requests. Now, with the help of new cloud infrastructures, such as Infrastructure as a Service (IaaS) or with various automation tools, with just one click or with some commands, developer can deploy application on one box, cluster environment, cloud-based environment or containerized environment. In this chapter, we will focus on the deployment process with Docker, an application containerization technology. We will have a detailed look into different aspects of Docker such as installation, configuration; benefits of Docker over virtual server node deployment; deploy application inside Docker; and how to make it available to the outside world.
Gradle plays one of the major roles in the build and deployment process. Developer can use a combination of different tools based on the requirement to automate the complete build and deployment process. Tools such as Jenkins, Puppet, Chef, and Docker help to create the build and deployment infrastructure. But for very simple deployments, some of the Gradle features can be useful. Gradle provides a variety of tasks that can automate some of deployment tasks as mentioned previously. Few useful tasks are as follows:
- Download task to downloading the artifacts (ZIP, WAR, EAR, and so on) and its dependencies.
You can download artifacts by just adding the list in the dependencies closure. In a similar fashion, you can download all the other dependencies needed to run the software. It is not needed to bundle the software with all the dependencies and make it heavy. It is good to download dependencies at the time of the installing the software to make it lightweight.
- Unzip or untar tasks to unzip the artifacts.
Once artifacts and their dependencies are downloaded, next step is to unzip or untar the artifact if required.
- Configure the application.
Configuration or localization of the application can be done in Gradle by adding custom tasks.
- Start/stop the application.
Start/Stop of the application can be performed using existing Gradle tasks, such as JavaExec or any other custom task.
In my opinion, though these tasks can be automated in Gradle, a better alternative would be a scripting language such as Shell script or Perl. Later in this chapter when we create an example of build and deployment pipeline, the role of Gradle will be a pure build and test tool. We will not explore any task or plugin specific to deployment. Now we will move on to the next topic, Docker, that has become very popular in recent years with the emergence of micro-service architecture.