Improving Developer/Contributor experience


I wanted to make a contribution to a real open-source project that is actually used by people and Zammad really looks nice in this regard. I instantly felt some kind of connection that money cannot buy.
Unfortunately, I had quite a few issues down the road on making my development environment work as intended.

So I’ve decided it would be nice to share some experience from my point of view, see feedback, and maybe make Zammad a little bit better place to contribute to.

What I would like to see

  • Easy and simple provision with meaningful defaults.
  • Simple configuration and fine-tuning for more specific cases.
  • Ability to modify the code and see instant changes in a working project, without rebuilding anything.
  • Standard workflow for testing.
  • One code base for everything. The code is aware of environmental variables. Deploying to production, development, testing environments is a matter of changing a single file.

Few of these points are straight out of Especially parts I (Codebase) and III (Config).

In 2018, the best and efficient way of isolating different projects from your OS is still Docker. I’ve noticed that there is a production-ready docker image deployed on the Docker Hub, so that’s what I’ve tried first.
While it does the job perfectly, I find it very difficult to integrate with the points listed above. It took me a few hours just trying to understand how can I switch to the latest development branch.

That’s where I started. I took the zammad-docker-compose and made it work with development first. You can see my results on konovalov-nk/zammad.

How can I run it?

First, you need to install Docker and set at least 4GB available for the container instances. On Docker for Mac and Windows it is done by going into Toolbar Icon -> Preferences -> Advanced -> Memory. Not sure if it is the same in Linux distros.

After that clone my repo and switch to develop-docker branch:

git clone && git checkout develop-docker && cd zammad

Copy the default database configuration and .env.example file:

cp config/database/database.yml config/database.yml && cp .env.example .env

By default, docker-compose up would run a development version but without attaching current folder as a volume. So we have to run it like that:

docker-compose -f docker-compose.yml -f docker-compose.development.yml -f docker-compose.override.yml up

After a while, you should be able to see docker processes are running and everything is healthy (don’t worry about zammad-testing being unhealthy though):

docker stats

From there, you can get Container IDs and get into them:

docker exec -it 5d594b5d82be /bin/bash

  • zammad-railsserver is a container to run rails console, rails db:migrate and other commands.
  • zammad-testing used for running RSpec and Rake unit tests.

Now, to make our application accessible as a meaningful URL, we have to add value of VIRTUAL_HOST (found inside .env file) to the /etc/hosts (or C:\Windows\System32\drivers\etc\hosts): localhost zammad.local

Now you should be able to access http://zammad.local and set up your local copy of Zammad, congratulations!


Zammad have thousands of RSpec and Rails tests. I don’t know how should I approach testing. It takes about 30 minutes on my old MacBook 2014 Pro to finish only RSpec and Rake unit tests. Even loading just one file through

bundle exec rspec spec/models/ticket_spec.rb


Finished in 6.93 seconds (files took 10.31 seconds to load)

That is a bit too much in my opinion.

What can we do about this? I suggest using something like spring to preload our test files between runs. It would be slow for the first time, but after that, it should work pretty much with little or no overhead.

Second, I would like to try how tmpfs could possibly speed up interactions with PostgreSQL. Here are some links I’ve found while looking out for solutions: one, two.

Third, I think we should be able to use modern multi-core systems effectively and be able to run a whole test-suite as fast as possible. For this, we could try using something like grosser/parallel_tests. Also, in Rails 6.0.0, a new application will run tests in parallel by default.

That’s pretty much all I wanted to say. Feel free to give a feedback. I’m in no way knowledgeable about the current Zammad ecosystem and if this change would break anything. For this, I need your help.

Thank you for your time!

1 Like

For dev environments use this repo:
Its made for quick testing / development and already uses the develop branch and has all processe in the same container (even if its not docker best practice).
But be aware that all data is lost if the container stops.