OUT OF DATE

Merge with Workflow

---

Development of microservices is difficult because they are: interconnected and remote. As such, we need to make sure we simulate the interconnectedness and have the feeling that we are working on the microservice as if it were on our laptop.

Local Development Support

The best way is to fire up all your services and run them somehow. The best advice is to port-forward to your databases in the cluster and use stage modifiers to change how your configuration is run.

wov-portforward - used to set a port locally that forwards to a pod in your cluster. this is a wrapper around kubectl port-forward. NOTE: If you are forwarding to an AWS service, this won't work.

wov-env --mod local --envs - This exports variables, that are configured from your secrets files from the 'local' stage, so for MYENVVARIABLE=\{{mymicroservice.{{STAGE}}.A}}, in stage cw (my initials), instead of using the secret mymicroservice.cw.A, it would use mymicroservice.cw-local.A. In this way, these stage modifiers in secrets are applied to the environment. NOTE: --mod has serious issues in configuration and should probably be avoided since you don't have granularity in settings per service. open issue.

Proxying

This seems like something useful: kubectl proxy --port=8090

Then, curl as needed with -X GET or -X POST.

This is not integrated into WovTools however.

Service Re-Routing to VH Development Pod

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

Features

• We don't worry about changing 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, npm link it
    • cd /path/to/myprivaterepo ; npm link
    • cd /path/to/myproject ; npm 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]