fineract-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ashok <as...@confluxtechnologies.com>
Subject Re: Microservices release question
Date Mon, 30 May 2016 16:46:13 GMT
Hi Myrle,

Release process looks very interesting and same time highly confusing, I am
wondering how small organisations or independent implementors will
understand this process to carry out their implementations without much
hurdles.

Regards,
Ashok

On Mon, 30 May 2016 at 7:57 PM, Myrle Krantz <mkrantz@mifos.org> wrote:

> Hi Fineract,
>
> I'm starting a new thread for a question which Roman asked in the multiple
> repos thread.  He asked how we'd like to release if we are dividing our
> code into microservices.  Assuming we want to do clockwork releases, there
> are three major alternatives:
>
> 1.) Release each microservice version separately, on its own schedule,
> 2.) Release a set of microservices as one release which are compatible with
> each other, taking the newest service version from the leafs of the
> dependency tree, or
> 3.) Release a set of microservice versions as one release which are
> compatible with each other, taking the newest service from the root of the
> dependency tree.
>
>
> 2 and 3 probably require a bit more background to understand:
> Microservices will be dependent on each other.  For example all services
> will depend on the tenant provisioning service, and on the service for
> managing users and permissions.
>
> So let's say you have services A, B, and C in multiple versions which
> depend on each other like this:
>
> Av1 -> {} (no dependencies)
> Av2 -> {}
> Av3 -> {}
> Av4 -> {}
>
> Bv1 -> Av1
> Bv2 -> oneOf(Av1, Av2)
> Bv3 -> oneOf(Av2, Av3)
> Bv4 -> oneOf(Av3, Av4)
>
> Service C: depends on B
> Cv1 -> Bv1
> Cv2 -> oneOf(Bv1, Bv2)
>
> In solution one, we'd release a new version of A as soon as it was
> complete, even if none of the other services were updated and still
> required older versions of A.
>
> In solution two, we'd release a source code tar ball containing Cv2, Bv2,
> and Av2.  Even though Av3 and Av4 exists we wouldn't include it in a
> release until all services were updated to be compatible with it.
>
> In solution three we'd release a source code tar ball containing Av4, and
> Bv4.  We wouldn't include any version of C because there would be none
> which is transitively compatible with the latest version of A. If C is a
> service which not everyone deploys, this may be acceptable.
>
> What do you guys think?  Keep in mind that in Apache the release is a
> source code release. It's signed and it should include all the source
> code...
>
> Greets,
> Myrle
>
>
>
> *Myrle Krantz*
> Solutions Architect
> RɅĐɅЯ, The Mifos Initiative
> mkrantz@mifos.org | Skype: mkrantz.mifos.org | http://mifos.org
> <http://facebook.com/mifos>  <http://www.twitter.com/mifos>
>
-- 
Regards,
Ashok

Sent from mobile device

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message