Testing Alfresco One with Docker

Showing results for 
Search instead for 
Did you mean: 

Testing Alfresco One with Docker

Active Member
4 4 8,866

Docker is really under the spotlight at the moment so we had a look at it to determine how it could help in our Continuous Integration (CI) pipeline.

This article intends to show where we started and what the benefits we are getting from Docker. 

Our infrastructure:

    • Bamboo CI Server

    • 16 Linux build agents

    • 4 Windows build agents

    • 1 Mac build agent

Most of our builds run on the Linux machines. Mac and Windows are dedicated to specific tasks and projects.

The complex combination of databases versions: 

We decided to start with a simple, yet highly important use case. As part of the automated tests jobs that our CI server runs, we test Alfresco against all the Relational Database Management Systems (RDMS) that we support.

That includes: PostgreSQL, MySQL, MariaDB, IBM DB2, Oracle DB, and Microsoft SQL Server.

We have access to a pool of machines that host different RDMS/Version couples. Multiple running builds can access the same machine simultaneously so we use a specific database name per build agent to avoid concurrency issues.

As we grow, the number of Alfresco releases increase and so does the nebula of supported RDMS. Adding new machines and maintaining the pool raises some interesting concerns:

    • Performance issues and race conditions due to the latency between the build agent and the database

    • The cost of hosting the pool of machines that are not used all the time

    • The process and the time spent to setup a new machine

DB-Testing-Before-Dockeron Complex test environment


Docker makes it easier:

The Docker approach gives us more flexibility and increases significantly our capacity to test Alfresco with a new version of any supported database.

Switching to the test environment based on Docker was fast and fairly easy. All we needed was to install Docker on our build agents and simply change the build command to override all the JDBC connection settings.

Not only we are now running the whole stack locally on the build agents, freeing us from any potential network latency, and concurrent use of the database but everything is isolated and we can now run any version of any RDMS we want without having to maintain live remote instances.

Last but not the least, even though we drop and recreate the database for our tests, this solution ensures that we always run in a fresh unaltered testing environment.

Simplification with Docker containers Simplification with Docker containers

Whenever it’s possible, we use the official images provided on Docker Hub. For Oracle DB and IBM DB2 we had to create and store them in our private registry.

What’s next?

As you may know the native support of Windows Server containers is in the roadmap of Windows Server 2016 but something even better has been recently announced. SQL Server will be released on Linux and Microsoft will even distribute Docker images!

We are looking forward to migrating that last piece of our testing infrastructure to Docker.