Best practices for Java Deployments
Tags: devops, java
Published: 2020-07-28 00:18:02

![enter image description here](https://lh6.googleusercontent.com/-mZlpI0ceJgA/T6GxtDMkMzI/AAAAAAAAAZg/slvbOJjzdkY/s413/compiling-new.png)
###### Image is a modified [xkcd commic strip](https://xkcd.com/303/). Credit and thanks goes to [Joseph Scott](https://blog.josephscott.org/2012/05/08/deploying-is-the-new-compiling/).
###### The original article can be found [here](http://www.sindi.co.za/blog/best-practices-java-deployments/).

The proper deployment of Java applications can be a cumbersome and a tedious process and the risk of failure is never higher than it is moment after deployment. Errors during/after deployment not only impact IT development and operations of the organization but also your customers.
In order to reach an optimal deployment process many project and DevOps managers and engineers have adopted best practices to improve the deployment process to mitigate deployment risks. There is no silver bullet, but here are some best practices for Java deployment, which we will examine in this article.

## 1) Do a reality testing
Testing deployment in a pre-production/staging environment is essential (if not crucial) for success. Pre-production environments should be as similar to the production environment as possible. **An ideal pre-production environment is composed of isolated hardware, software and data that mirror a front-line production environment in every way.** Typically, functional, regression as well as performance tests are conducted to ensure that the application still meets the requirements (functional & non-functional) once deployed in production.
It is extremely important that the testing tools used in pre-production testing are configured to resemble users' activities using a complete user profile (simulating real production user activities).

## 2) Use an artifact repository
Today's real world of development, applications are not static binaries, but a collection of objects that have an inter-dependencies on each other. A JavaEE Web Application (WAR - Web Archive) may have dependencies of any kind of common functions, such as SLF4J, etc. and these dependencies have their own versions. In a collaborative development environment, you want your developers to share the common libraries and the application can still be built and run in all your environments without breaking deployments (due to missing libraries or incompatible library versions).

Artifact repositories are great at managing multilevel dependencies. This dependency management is critical in reducing errors and ensuring that the right components are included with each build/deployment/release, especially in large scale applications. Also, you can apply governance process to your artifacts such as security, licensing, etc. You can check out repositories such as [Apache Archiva](https://archiva.apache.org/index.cgi), [Sonatype Nexus](https://www.sonatype.com/nexus-repository-sonatype), [Artifactory (by JFrog)](https://jfrog.com/artifactory/), just to name a few.

It is, therefore, essential that all your Java applications are versioned. For Mavenized Java projects, you specify your application version as well as declare your dependency in a `pom.xml` file, specifying the source of your artifact repository and voila, your application (with it's inter-dependencies are shared). This is particularly handy when applying a rollback strategy.

## 3) Have a rollback strategy
Should you ever find yourself in a position where a production deployment fails or your Java application introduces a (new) critical flaw/bug in your application, the best policy will be to be to rollback your application to a known working version of your application. It's, therefore, essential that a rollback strategy is put in a place. One simple strategy is, if necessary, to backup your production application application and, should rollback is initiated, undeploy the defected Java application and deploy the backup application. If you have an artifact repository you can simply redeploy a previous version of your application back to production.

There is no silver bullet for a rollback strategy. The Java team as well as the DevOps engineer should sit down and formulate what constitute as failure for rollback, the best rollback strategy and document the rollback procedures.

## 4) Document, document, document
A general practice for Java developers is to write code and documenting their code using code comment, highlighting the purpose and intent of the code. Documentation is your best friend. Prior to production deployment, make sure that you have a **detailed and accurate document** that lists the stakeholders of the projects, the features and bugfixes introduced in your Java applications release, the backup plan, deployment plan, rollback plan, a maintenance plan and communication plans & training plan (if needed).  Furthermore, if your DevOps engineer ever leaves, the documentation can be used to retrace their steps and reproduce the deployment process they created.

## 5) Automate your deployment process
Manual deployment is the least effective option to deployment as it can introduce errors, especially in large scale and frequent deployments. One of the biggest challenge in Application Lifecycle Management (ALM) is dealing with the tasks of application deployment, there are various tools that allows us to do automated deployment.  Make sure that you invest time in choosing the right deployment tool. For Java applications, factors to consider when choosing your deployment tool should include:

- **Automated Build tool**: Your Java application must be able to be built in the environment where deployment will occur effortlessly. Also, your build tool should identify dependencies between files and package them for distribution (Make sure that your deployment tool can integrate with your Artifact Repository). An automated build tool such as [Apache Ant](http://ant.apache.org/) or [Apache Maven](https://maven.apache.org/) are well-known tools available for free for project build. 
- **Load Testing and Performance Testing**. Many application comes with performance KPIs & tools such as [Apache JMeter](https://jmeter.apache.org/), [SmartMeter.io](https://www.smartmeter.io/) are suited for such purposes. Some of these tools can be easily be integrated in CI tools such as Apache Jenkins and/or Atlassian Bamboo. 
- **Automatic deployment**. Make sure that the tool can deploy and install the application to the target environment. 

## 6) Put the people first.
Deployment is not just a technological process but also a human process and it is a team effort in order for it to be successful, the most important includes your stakeholders (inside and outside your organization) as well as your end users. It is, therefore, crucial that you understand their requirements, needs and expectations otherwise your deployment will be met with resistance. **Communication** is crucial in this regard.

Feel free to engage with me to make your IT journey a comfortable ride and your ideas implemented.