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
#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!
I'm also looking for more suggestions of how people will want to use Hoverfly with Java projects, and so please do give me a shout via twitter @danielbryantuk if you have any ideas!
One sticking point; what if the monolith does not have an endpoint you can call with an http request? What if you have a client that consumes the back end with server rendered pages and no services are exposed with url endpoints? Do you first have to make the monolith's internal functionality accessible via http requests?
Adding 'seams' into the monolith (and exposing this typically via REST or AMQP) is the most effective way I have found.
The alternative is to 'screen scrape' the data returned from calling the monolithic application via the interface exposed now. For example, calling a website page, parsing the HTML data returned, and extracting what you require. However, the code/algorithms you have to write are typically complicated, and the resultant code often fragile and highly-coupled
I agree - I'm seeing some application frameworks even encouraging developers to expose CRUD functionality via REST (Spring Data REST, I'm looking at you)
There may be a few narrow use cases where this is valid, but in general we really should avoid doing SQL joins over HTTP :-)
As Stefan argues in the talk, one of the original sins with SOA was caring too much about the services (and potential "reuse"), and forgetting about the notion of offering a cohesive piece of business functionality i.e. a bounded context with well-defined responsibilities
Great comments Daniel, and I think you've touched on one of the key points that we're seeing with the rise of mob programming and lean practices etc "it's really completely re-structuring what we think about when we think about a tech team delivering value"
This is the sticking point for many people, as we still like to draw analogies between coding and typing, or coding and physically building structures (which inherently are limited by the application of manual labour), rather than seeing it for the value-creation/design-thinking act that it actually is (and accordingly the need for good imagination and decision-making abilities)...
Wow! I couldn't have said it better myself. Having worked across a variety of codebases and teams over the last 10+ years, it has become obvious to me that delivering software is an inherently social activity (at least the delivery of valuable software)
IMHO, the reason we've seen the rise of XP, Behaviour-driven Design (BDD) and DevOps is that each part of the software delivery community is gradually coming to this conclusion within their own realm
Mobbing for me just makes sense on so many level, especially from the point of view of adding 'expertise' to a problem/solution:
Not sure on how to integrate the latest language feature into your code - bring someone with experience into the mob...
Not sure how this feature could be tested - bring a QA/tester into the mob...
Not sure of the infrastructure requirements of this new database - bring an operator into the mob...
In my experience working as a consultant across multiple organisations, not enough people have been doing this.
As for a putting a name on it - a name can help spread the idea (ubiquitous language and all that), but it can lead to abuse and cargo-culting.
I believe a label is often helpful during the 'innovation' and 'early adoption' diffusion of innovation phase, and this is firmly where mobbing is at the moment
I see lots of discussions after code has been cut ('why this design?', 'why this library?', 'did you consider this?'), which would have been much more valuable to have as the code is being written.
With mobbing I'm thinking you can answer these questions and discuss opinions at the most appropriate time in the software creation lifecycle...
I found it incredibly stressful to try to answer those questions before I finished. Pair programming meant I could never try anything new, because I couldn't answer those questions immediately.
Huh. That hasn't been my experience. Often I've had a pair say, "Can we try something?" And I'm happy to say yes. I learned a ton that way.
I'll add that when I'm just messing around with something, that's often solo coding time. E.g., trying out a new library just for the fun of it, or playing around with approaches to a problem. But for me that's throwaway code, so I don't need the quality boost or the shared understanding that comes from pairing
I think this reply thread is confusing the specific, i.e. the technique of 'mobbing', with the general, i.e. the (mis-management) approach to fixing issues with 'all hands to the pumps'.
The only thing the Unruly team is dogmatic about is delivering valuable software. The techniques they talk about are simply this - techniques.
In my work as a consultant there is rarely a 'one-size fits all' technique to developing a feature, but knowledge of several approaches is very valuable.
This is the purpose of the article - to allow you to consider the addition of 'mobbing' to your existing approaches of single development and pairing
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