1

Maybe the whole setup is wrong but imagine your task is to model a system, or set of systems using Docker, where exact system configuraton can be tricky.

The workflow resulting from it seems like series of making small changes, waiting to analysing logs, changes, waiting... It seems like during an hour of work you could manage several iterations, but waiting is mind-boggling, though it already takes place on top of base images and inside-container work is done as well to try out things. Additionally, often this work can block many others.

Question: how to speed up this process? Do you guys use powerful appliances to reduce the cycle periods which is in term of lean manufacturing a clear waste given cost of systems compared to human time (imagine any change would be landing in the target environment always in just one second)? Or is the workflow wrong?

Improve this question

2 Answers 2

Reset to default
1

In some cases, depending on the actual configurations being targeted, it might be possible to try the effect of various changes live, using other automation tools, and only update the docker images (which acounts for a big chunk of that waiting time) after the bulk of the config changes are eliminated.

Stabilizing first the common/base docker image used across most/all of the candidate variants and sharing it would also help.

Improve this answer
1
  • that is, the work is actually building educated increments to base images. For example, in the Java world the tool JRebel is successful exactly for this reason to save time wasted for to wait for compiler results.
    – Ta Mu
    Commented Jun 27, 2017 at 15:16
1

Indeed that there can be a compound set of measures to reduce build times.

For example:

  • Consider using RAM volumes for builds to reduce filesystem I/O latency
  • Consider defining more build targets (Vakilian et al. 2015) and if possible build them in parallel with more hardware build agents
  • Consider parallel execution if supported by software build agent e.g. Maven multi-thread mode however it might be not thread safe and corrupt builds in an unexpected way
  • As suggested above, evaluate which part of environment can be reused as Docker base image i.e. save time for unneeded repeated tasks (however on long term you still need complete rebuilds to validate integrity of external dependencies)
Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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