One, it depends on its own ssh-pool package for connecting to servers, which was easier to configure - it also didn’t require storing credentials in the project repo since it uses existing SSH keys. Ultimately, I settled on Shipit for a couple of reasons. I ended up implementing a deployment task using both to get a feel for how they work and they turned out to be very similar. Searching npm turned up Shipit and Flightplan as two promising alternatives.
While Grunt could handle everything we needed, configuring multiple packages to accomplish a task like this feels a little too fragmented and brittle. We already rely heavily on Grunt to automate development tasks, so installing Node.js packages with npm is second nature. Able to work with our existing tools and not introduce a new technology into our stack.Secure by not requiring credentials in plaintext or even saved in the repository.Most of all, the solution needs to be frictionless, so it should be: Finally, we should be able to push a tagged release to our distribution repository.Running our themes on a live site also helps us discover any issues before pushing a release out to our customers.
SHIPIT RSYNC MKDIR UPDATE
We should be able to easily update our demo servers with the latest version of a theme or push a quick bug fix.During development, we should be able to deploy a theme to a testing server so the team is always on the same page.While researching potential solutions, I had a few goals and loose requirements in mind:
Most deployment processes tend to focus on deploying a site or app, whereas when we’re working on a theme, we’re primarily interested in deploying individual packages independent of the platform. Jeremy Felt’s series on deployment workflows earlier this year inspired me to write about and document our process for deploying themes.
0 kommentar(er)
