danielbryantuk

We put together the Kubernetes Developer Learning Center for folks looking to bootstrap their k8s hands-on experience: https://www.getambassador.io/kubernetes-learning-center/

Combined with the K8s official docs https://kubernetes.io/docs/home/ and GCP getting started guide, this will give you a good tour of the tech: https://cloud.google.com/gcp/getting-started

For a general overview of DevOps and the principles behind this, you can't go wrong with reading "The DevOps Handbook" and researching the "Accelerate" metrics

I wrote a blog post a couple of weeks ago that may answer some of your questions:

https://www.specto.io/blog/recipe-for-designing-building-tes...

In answer to your specific questions

#1 If you are testing system-level (end-to-end) functionality the separate repo definitely. If you are testing service (component) level functionality then store tests in the same repo as the service and virtualise/mock dependent services

#2 Opinions in the industry are split here - Adrian Cockcroft often suggests using client libraries (as do the Datawire.io team), but I don't always because of the developer maintenance cost of these libraries (and forget it if you are using multiple/polygloy languages in your stack).

If I understand your question correctly I think you would benefit from reading about Consumer-driven Contracts, as this will help you detect contract/API breaking changes

#3 You can either entrust your build pipeline to manage this (I've used the Jenkins promotion plugin to do this kind of thing), or you can use yaml config files to specify service runtime dependency requirements (kind of like Maven or Ruby Gems etc, but at runtime), or if using REST/HTTP you can deploy two service versions at any given time and user the 'Accept' request-header to specify which versions of services can communicate with each other

Feel free to DM me if you have any further questions!