I'm working on a project where an increasing number of small mini apps all share nearly the same tooling - makefiles, dockerfiles, jenkinsfiles and webpack configs, along with a couple of scripts, are all rigged for each project to give a standard set of dev tools for each project.

This is becoming increasingly difficult, as updates to the build process mean changing what is essentially the same file in each project in order to keep them all inline and working. I'd like to get them into their own repo, but the tools, especially make and docker, are very dependent on their location in the file structure. I'm tempted to use another makefile that just templates in what's needed to populate all of these files in the correct places, but that feels a little bootleg.

Have you worked with extracting project tooling like this? If so, how did you work around the requirements of these tools?


We had almost the same problem in the past - not for microservices, not with docker, but for a system containing lots of small programs (more than 100). Tooling includes build configurations, documentation generation, versioning and deployment for all of them.

Over the years, we have developed some strategies which helped us to keep the system manageable:

  • Rigid naming conventions for the tools. Configuration files or tool scripts for the same purpose should be named strictly following the same rules in each of the projects. That starts to be helpful just for a global search-replace over all tool files of a certain kind, but it also helps to implement generic tasks like "run all scripts of a certain kind for all projects". Convention over configuration can help to reduce maintenance efforts a lot.

  • centralize the things you want to have in just one place (for example, certain absolute paths), and use include-mechanisms and variables to access the centralized configuration. Avoid having to manage the same information in several different places.

  • if a tool's config file does not have an include-mechanism or variable mechanism, find other ways (like a generator script for the configs) to build your own one - or find a better tool. For example, a very powerful standard for makefile generation is CMake, which AFAIK provides such features.

  • automate whereever you can. We use sometimes simple scripts, but for versioning and other tasks, we have also created tools with a GUI to implement a semi-automatic process with visual checks of what is going on.

  • document your conventions, and make sure the documentation can be found easily by anyone in the team.

In the end, it is not just "one" measure for managing a huge number of similar apps, but a mixture of several measures, depending on the requirements inside your system and the specific tooling.


Creating templates


What I did in the example of docker is: 1. created a main (or template) project, that builds the main Dockerfile. Let's call it FOOEnvironment. 2. Publish it to our own docker registry (e.g. Artifactory, GitLab or even Docker Hub) 3. All of our microservice projects have a simple Dockerfile that looks like this:

FROM: FOOEnvironment:1.0

# do anything specific


→ You will still need to manage version numbers, but it makes it easier - in my opinion. I'm curious what other people do to address this problem.

Other files

This is tricky. I would attempt to use Continuous Integration (CI / build process) pipeline, which could copy dependencies together from a template project – as long as it is easily viewable. However, it still introduces duplication of CI-scripts, which may be reduced through templating...

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.