Infrastructure/Build/Deployment Automation

• Business goals
  • Lower development, testing and deployment costs
  • Increase code quality
  • Increase reliability of software delivery
• Business goals are going to be supported by automating following areas
  • Application compilation, build, running unit tests
  • Application packaging (executable jars or wars)
  • Test Coverage check
  • Code Quality check
  • Creating local development environment
  • Provisioning of local/staging/QA/production machines (servers/VMs/containers, needed libraries/tools, configuration)
  • Configuration Management of the machines
  • Configuration Management of applications
  • Deployment of applications
  • Unit testing
  • Integration testing
  • Performance testing

• Gradle (as part of Grails 3)
  • Unified build lifecycle
  • Declarative definition of dependencies
  • Plugins/Tasks for test coverage, code quality etc. (Cobertura, JaCoCo, SonarQube)
  • Integration to popular IDEs (IntelliJ IDEA) and Build servers (Jenkins)
• Spring-boot (as part of Grails 3)
  • Easily package applications as standalone JARs (with embedded Tomcat/Wildfly/Undertow etc.) or WARs
  • Unified approach to auditing, health checks etc.
• Docker
  • provision testing machines (containers) for different environments
• Vagrant/VirtualBox
  • provision testing machines (VMs) for different environments
• Ansible
  • provision needed libraries and dependencies (DB, Application Servers etc.) to machines
  • deploy the application and environment specific configuration to machines
  • deploy the application itself to machines and control it's lifecycle (starting/stopping)
  • any other sort of automation of environments
• Jenkins
  • apply versioning strategy
  • checkout and build the source code of application
  • perform unit tests
  • perform test coverage and code quality checks
  • provision staging environment
  • deploy application to staging environment
  • run smoke/integration/performance test on the staging environment
  • automate deployment to QA/PROD environments

The research was performed mainly to support the Fiber project automation, but is intended to be also applied to other projects in the company.

The project is implemented using Grails 3, which uses Gradle and Spring-boot. Gradle spring-boot plugins are used to package the application as a WAR file. Application can be run locally using Gradle (gradle task bootRun). JaCoCo Gradle plugin is configured to perform test coverage analysis (gradle task JacocoTestReport).

Docker and Docker Compose is used to create local testing environment comprising of app server and db server (to be then provisioned using Ansible). The base image used for these is centos/6.6 to make this in line with our QA environments. We attempted to install Docker to the build server (mentioned below), but this has failed due to old version of Linux on the server. In future we would like to upgrade the build server to up-to-date linux and use Docker to provision machines for automated testing.

Vagrant was attempted to be used as replacement for Docker on the build server, but it has also failed due to old linux installed there. We might consider using Vagrant to provision machines for automated testing, but we will favour Docker if possible.

Ansible playbooks and roles are implemented to provision the application dependencies (install/configure MySQL on DB and Java/Tomcat on App server). Other playbooks are implemented to provision the application configuration (specific tomcat configuration, link to DB, etc.) and finally to deploy the build artefact to the server. These scripts are currently working with local Docker environment and also with our internal QA testing environments. The Ansible is now also used in order to configure CAS (SSO solution) and HTTP loadbalancer.

Jenkins 2 is installed on our servers (please check Jenkins 2 for more details). It is configured to poll the SCM (Git/BitBucket) for new commits in application repository. Every time new commits are detected, the application is built, assigned version, unit tested, analysed for test coverage and the build version is pushed as tag back to the HEAD of respective GIT branch. There is also a Jenkins job, which is capable of taking the latest stable build of the application and deploy it to desired environment (using Ansbile).