1

I am new to continuous delivery, so please help me understand if my ideas are incorrect, I have XY problems, etc..

My organization runs web services, with services-oriented architecture. Currently, we have about a dozen services. Naturally, these services share some code in common. To date, we've done batched releases every 2 weeks. We want to move to CD

We don't want to deploy every single service for every single change. It can be unnecessarily disruptive, time-consuming, and it isn't scalable. So we'd like to release only the services that have changed. This also applies to common code. So if service A and B have project C's code in common, and C changes, we'd like to release A and B.

  1. Does this sound like a reasonable idea of what continuous integration would look like?

  2. Are there any tools/processes that help in deploying only the minimal amount of changes for changed code?

It seems like large organizations like Google and Facebook that use continuous delivery have these same needs, though I haven't discovered how they do it. (My problem isn't nearly at that sort of scale, but the basic problem seems similar.)

Improve this question
3
  • If you can't release services independently, you don't really have a service-oriented architecture. – Benjamin Hodgson Mar 7 '15 at 7:20
  • @BenjaminHodgson, I can release services independently. – Paul Draper Apr 6 '15 at 2:54
  • Perhaps I misunderstood you: "We don't want to deploy every single service for every single change" suggests that you don't currently have independent releases – Benjamin Hodgson Apr 6 '15 at 13:55
1

Well, to my understanding, you already have your answer. Replace "common code" to "common business rules" and it becomes obvious. If the behaviors of both services A and B have changed, you have to redeploy both A and B.

However, I think this situation smells familiar... Do you have "common code" for things that aren't really common business rules? If you do, you're in for some surprises.

I may just be straying from the topic here, but I've seen this happen before. Quite often, people see two similar blocks of code and think "Hey, I've seen this before... A for-loop at a collection of Orders, filtering by isSubmitted... Yep, just like in that other component. I think I can extract that into a common object!". This is soon followed by a "Hey guys, look, I've just removed some duplication!" (I may or may not be quoting myself here...).

What happens next is surprising: One component changes that behavior, while the other doesn't. Then you go to the "common component" and try to slice into smaller "reusable pieces", trying to keep it as common, but different for each dependent component. This happens for a while, until people finally realize that the code shouldn't really belong there.

Turns out this is a often the result of following DRY and "remove duplication", without considering that, in a more abstract level, there really isn't duplication in the two very similar blocks of code. Now, I'm not saying DRY and "remove duplication" are bad at all, but that you must also pay attention to the Single Responsibility Principle.

Sometimes, two identical blocks of code serve different roles in the system, and just accidentally happen to do the same thing. But since the roles are different, the requirements for a role may change while the other doesn't. I recommend watching this talk about the SRP, where that same example is given.

It may look like I've strayed too far off from the topic here, but SRP is very closely related to continuous delivery, exactly because it aims at reducing the amount of accidental coupling between modules (and services), allowing changes to be kept at a minimum range of impact, to a point where only one module has to be redeployed.

But hey, I may really just have strayed off, and you really just have common business behavior between your services. If that's the case, as I said before, you already have your answer. Anything that changes get redeployed, and you won't have to find new tools for that, since this should be obvious, because you also need to test those services.

Improve this answer
5
  • I don't think "strand" is the right word here. Did you mean stray? – raptortech97 Dec 6 '14 at 19:47
  • 2
    I like this answer but remember that he's asking about operational deployments not about object oriented design. I think a better answer would be something like "put each module in its own git repository" and "use a tool like jenkins to create the dependencies between each module and let it decide what to deploy depending on what repos have changed". – RibaldEddie Dec 6 '14 at 20:09
  • The "common code" isn't so much business logic as common utilities, like some HTTP utilities, or a thread pool that logs exceptions, or other stuff. – Paul Draper Dec 6 '14 at 20:19
  • 1
    @RibaldEddie, that would be one approach. I happen to know that Google, Facebook, and Twitter use a single repo, but that is a possibility. – Paul Draper Dec 6 '14 at 20:23
  • Doing it from a single repo is certainly possible, particularly if you are using package management like RPM and have spec files for the components. So you can create packages from parts of your source tree. – RibaldEddie Dec 9 '14 at 20:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.