4 ms·

For sure, it could be used that way. But, a lot of people were comparing this unfavourably to how they currently manage their dev workflows. My point was that t

• 0xbadcafebee 4y ago
  I think this is the workflow most people should be moving to: immutable development. If your dev environment's state mutates and deviates from the rest of a team's (or away from production), the deviation introduces bugs. This tool lets you "start fresh" with the correct environment every time, but (I imagine) also lets you update that shared environment by pushing a new container. In this way you ensure everybody is developing off exactly the same thing, and can easily update that shared environment, but nobody clobbers anybody else's WIP, and you can test new changes in your own container, even persisting your own configuration using persistent volumes. Sadly, this does not support port forwarding, which is the final feature necessary to do remote development (run your web app remotely, see it in your browser locally).
  • janosdebugs 4y ago
    If you build from the libcontainerssh sources on GitHub it does. We just haven't released it yet. :)
    • 0xbadcafebee 4y ago
      Is there some docs on how to use it after I've compiled it? I'd like to try it out... Evaluating solutions like these right now, could be really useful for us