-
Notifications
You must be signed in to change notification settings - Fork 3
DeploymentPipeline
Every time when a change is committed to version control, the expectation is that it will pass all of its tests, produce working code, and can be released into production. With configured deployment pipeline after every commit, changes are delivered to the customer (or at least deployed on production-like environment).
Please remember that deployment in this context means deployment to application server, not deployment artifact to the enterprise repository.
Deployment pipeline is configured in a separate project module modular-war-deploy. Deployment configuration is environment specific and should not obscure main project modules. In addition, all deployment configuration is defined within the separate profiles which are not activated by default. When deployment profiles are disabled the module is built without any deployment action. It is useful when you need to release the whole project, and definitely don't want to deploy application on the server during releasing.
Profiles env-dev, env-qa and env-prod define deployment configuration for each target environment. All configuration entries common for all environments, are defined in deploy profile. Profile deploy is activated automatically when one of env-dev, env-qa, env-prod profiles is activated by command line option.
Regardless of deployment target environment, the following flow is configured for the deployment pipeline:
- Web application
modular-war-webappmodule is downloaded from the enterprise repository (WAR file). - Optionally, overlay with environment specific configuration is applied . Don't overuse overlay, configure environment specific settings as application server JNDI entries.
- Final WAR file is uploaded and optionally deployed on the application server.
- Smoke tests are executed, to ensure that application has been deployed and it is up and running.
There are various method to upload files to the remote server, the most straightforward is to use one of the Maven Wagon providers. But Wagon does not support remote command invocation, needed to stop and start application server. If remote command invocation is necessary to complete deployment process, SSH could be used.
Deployment pipeline should be configured as a Continuous Integration (CI) server build plan(s). There are many advantages over manual execution:
- It could be faster; SCM, CI server and application server are very often co-located. Developer workstation is far, far away.
- Deployment on DEV could be fully automated.
- Deployment on QA and PROD could be a one-click button operation, no more mistakes and typos.
- Deployment on QA and PROD could be self-serviced (by QA or OPS teams).
Let's assume that developer has a full control over DEV environment (with SSH access). Profile env-dev is configured to use Ant task <scp/> to upload WAR file and task <sshexec/> to restart application server. Define the following build plan trigerred after every commit:
mvn -B -U clean verify -Denvironment=dev \
-Dmodular-war-deploy.sshUsername=... \
-Dmodular-war-deploy.sshPassword=...
Option -U is crucial, to ensure that latest SNAPSHOT version will be deployed.
On Bamboo CI server you can configure Quite period. It allows you to delay building after a single commit is detected, aggregating multiple commits per build.
The modular-war-deploy module is configured to deploy on JBoss application server. JBoss startup script delivered with application server distribution is a crap, use this one: JBoss Startup Scripts
In the perfect world deployment on DEV, QA and PROD should be the same. But in reality you cannot automate deployment on QA and PROD due to formal process restrictions. Automate what you can, than. In the following scenario WAR file and descriptors are uploaded into dropfolder, network share configured as a place for WAR files queued for deployment.
Profiles env-qa and env-prod are configured to use Maven Wagon. WAR file and descriptors are uploaded, but application is not deployed automatically. Smoke tests are disabled.
On the DEV application server, latest SNAPSHOT version is deployed. On QA and PROD only released versions are allowed. One of Continous Delivery principles is to keep traceability between deployed binaries and source code. And the SCM revision number is not good candidate, releases are much better.
Define the following build plan trigerred manually (one-click operation):
mvn -B clean verify -Denvironment=[qa|prod]
Credential for Wagon provider are configured in settings.xml. It is advantage over SSH Ant task configuration in env-dev profile. Passwords in settings.xml can be encrypted for security reasons.
Location of target directory can be specified as modular-war-deploy.wagonUrl property, e.g:
-Dmodular-war-deploy.wagonUrl=dav:http://host/dropfolder
To deploy released version, SCM configuration section on the CI server needs to be configured to checkout the code from the SCM tag. Check CI server documentation how to parametrize SCM location.