< Home : Workflow > Workflow Locally - Workflow On Cluster - Workflow To Cluster - Workflow Rolling Stages

Out of Date

---

Modifies a running service in your cluster, to route it to the vh Kubernetes pod, which acts as our development machine. Then, you push all your code there and run/edit as you please on that pod. When you are done, pull it back locally then push/deploy as normal.

Features

• We don't worry about confusing configuration because we operate inside the running cluster.
• Data persists on vh, even if the pod dies.
• Env vars are in vh, and can be changed in shell or on the vh (via wov-deploy --conf-only and wov-vh --restart).
• Push and pull data to vh easily (wov-vh-pushgit and wov-vh-pulldir)
  • We check local changes to repos before pulling them back, to avoid overwrite
  • We avoid private repo key issues this way
• Routes back to running pod with one command

How To

• push development environment to vh pod

  • wov-vh-gitpush
  • ex. wov-vh-gitpush ../plugin-engine:master -> pushes the current project and the master branch of plugin-engine

• route the service for the microservice to vh. ex. plemrl

  • wov-vh --route-service [service]

• log in to vh for development

  • wov-vh -l

• on vh, alter dev environment to use other pushed repos

  • ex. for NodeJS, if you want to use a local codebase dependency, yarn link it
    • cd /path/to/myprivaterepo ; yarn link
    • cd /path/to/myproject ; yarn link mylib

• do development

  • edit code, build, start/stop service on port, etc.

• pull data back locally (to check into code repos) on a per-directory basis

  • ex. cd /path/to/myprivaterepo ; wov-vh-pulldir cd /path/to/myproject ; wov-vh-pulldir
    • NOTE: this works differently, as it pulls directories you are in, not like wov-vhgitpush

• Now check in to git and push/deploy

• To restart a service:

  • wov-deploy [service] ex. wov-deploy plemrl

• To route normally for the service (i.e. undo your routing to vh for development)

  • wov-vh --unroute-service [service]