Help get this topic noticed by sharing it on Twitter, Facebook, or email.

Borders of pipeline, component, application in "Engineering Practices for Continuous Delivery"

Hallo

I watched the videos of the "Engineering Practices for Continuous Delivery" (http://shop.oreilly.com/product/11000...).

The video describes the importance of creating a component build pipeline. The example uses two backend-services and a web-ui. I assume this is the application that is referred to? The borders of an application are not that clear to me.

There is also quite a lot on Microservices. The way I understood it, is that such a service is created by an autonomous team. In the example above that may be two or three teams creating those services. So what sense would a component pipeline make? It would create dependencies between teams one tried to avoid on a dependency level.

So what was "application" referred to? And does one really build a complete pipeline of all services available? As the deployment of one service does not necessarily cause any other action. What "components" should a pipeline contain when every service is a microservice that is independently developed in its own lifecyle? Or was that referred to the web-ui plus its backends to be part of that pipeline?

The borders of component, application and the pipeline are not clear to me.

Any thoughts?
1 person has
this question
+1
Reply
  • Hi Werner,

    I passed your message on to the author of that video and he responded with this note:
    -----
    ——————————————————————
    The video describes the importance of creating a component build pipeline. The example uses two backend-services and a web-ui. I assume this is the application that is referred to?
    -~-~-~-~-~-~-~-~-~-~-~-~

    Generally, yes, when I refer to a specific application. Most of the statements made in the video are broadly applicable.

    ——————————————————————
    In the example above that may be two or three teams creating those services. So what sense would a component pipeline make? It would create dependencies between teams one tried to avoid on a dependency level.
    -~-~-~-~-~-~-~-~-~-~-~-~

    Typically, each team has a deployment pipeline they use to apply all these practices. The “application" in an integration point in this kind of architecture, so it also has a component pipeline that uses the individual services as dependencies. When one of those services updates, it initiates a build of the “application”. A common practice used by developers to prevent integration point breakages is Consumer Driven Contracts. So, services have semantic dependencies but no technical architecture ones.

    ——————————————————————
    The borders of component, application and the pipeline are not clear to me.
    -~-~-~-~-~-~-~-~-~-~-~-~

    Components are parts of applications, either libraries (compile time dependency) or services (run time dependency). Generally, any deployable artifact has a deployment pipeline, which may feed into an integration point. Application in a service-based architecture can be thought of as a coordination point between services, with some additional logic added for specific cases. But “application” could also be a monolith with a bunch of library dependencies. I’m vague in the video because the engineering practices in this regard are the same: components and applications have pipelines because they are deployable.

    Hope that helps clarify.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. kidding, amused, unsure, silly happy, confident, thankful, excited indifferent, undecided, unconcerned sad, anxious, confused, frustrated