Answers: <p>In some cases, depending on the actual configurations being targeted, it <em>might</em> be possible to try the effect of various changes <em>live</em>, 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.</p>
  
  <p>Stabilizing first the common/base docker image used across most/all of the candidate variants and sharing it would also help.</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-06-27T15:16:56.283Z
Answers: 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.
Answers: Ta Mu
Answers: CC BY-SA 3.0
Answers: 2017-06-27T15:05:17.407Z
Answers: 2017-06-27T15:05:17.407Z
Answers: Dan Cornilescu
Answers: <p>Indeed that there can be a compound set of measures to reduce build times.</p>
  
  <p>For example:</p>
  
  <ul>
  <li>Consider using RAM volumes for builds to reduce filesystem I/O latency</li>
  <li>Consider <a href="http://dl.acm.org/citation.cfm?id=2818772" rel="nofollow noreferrer">defining more build targets (Vakilian et al. 2015)</a> and if possible build them in parallel with more hardware build agents</li>
  <li>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</li>
  <li>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)</li>
  </ul>
  
Answers: CC BY-SA 3.0
Answers: 2017-09-18T08:48:21.100Z
Answers: 2017-09-18T08:48:21.100Z
Answers: Ta Mu
Body: <p>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.</p>
  
  <p>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.</p>
  
  <p><strong>Question</strong>: 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 <em>waste</em> given cost of systems compared to human time (<strong>imagine any change would be landing in the target environment always in just one second</strong>)? Or is the workflow wrong?</p>
  
Tags: <systems><workflow><checklist>
Title: 1 second system engineering work cycles: educated workflow setup for Docker-driven development
UserDisplayName: Ta Mu
ThreadText: # 1 second system engineering work cycles: educated workflow setup for Docker-driven development
  
  (Asked by: username_0 on 2017-06-27)
  
  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?
  
  **Tags:** systems, workflow, checklist
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_1 on 2017-06-27. Score: 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.
  
  > **Comments:**
  > **username_0**: 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.  
  
  ---
  
  ### Answer by username_0 on 2017-09-18. Score: 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)](http://dl.acm.org/citation.cfm?id=2818772) 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)
  
  
  ---
  
  