<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Workflow on Random Musings</title><link>https://chengl.com/tags/workflow/</link><description>Recent content in Workflow on Random Musings</description><generator>Hugo</generator><language>en-us</language><copyright>Cheng Long</copyright><lastBuildDate>Sun, 30 Jul 2017 16:07:37 +0000</lastBuildDate><atom:link href="https://chengl.com/tags/workflow/index.xml" rel="self" type="application/rss+xml"/><item><title>Docker Workflow</title><link>https://chengl.com/post/docker-workflow/</link><pubDate>Wed, 25 May 2016 09:07:00 +0000</pubDate><guid>https://chengl.com/post/docker-workflow/</guid><description>&lt;p&gt;In my previous posts, I demoed how to orchestrate Docker with &lt;a href="https://chengl.com/orchestrating-docker-using-swarm/"&gt;Swarm&lt;/a&gt; and &lt;a href="https://chengl.com/orchestrating-docker-with-kubernetes/"&gt;Kubernetes&lt;/a&gt;. They all assume the Docker image &lt;a href="https://hub.docker.com/r/chenglong/simple-node/"&gt;chenglong/simple-node&lt;/a&gt; is already there and ready to be deployed. But how to develop that image in the first place? How to streamline and automate the process of developing it on local machine, building and testing it on Continuous Integration (CI) server, and finally deploying to production?&lt;/p&gt;
&lt;p&gt;This post introduces one possible Docker workflow.&lt;/p&gt;</description></item></channel></rss>