We should create a docker image and host it on docker hub for small organisations. These users would install docker, and run a single command to start the system. They wouldn't even have to download our compiled source directly; docker does that for you. We would need to figure out how to make installing a valid certificate for their domain in their docker image easy.
The answer to that question for larger organisations who want to take advantage of the scalability that microservices offer, particularly ones which wish to adjust the code before deploying it in their environments, will depend on how we answer the question I started this thread with. Greets, Myrle *Myrle Krantz* Solutions Architect RɅĐɅЯ, The Mifos Initiative mkra...@mifos.org | Skype: mkrantz.mifos.org | http://mifos.org <http://facebook.com/mifos> <http://www.twitter.com/mifos> On Mon, May 30, 2016 at 6:46 PM, Ashok <as...@confluxtechnologies.com> wrote: > 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 <mkra...@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 > > mkra...@mifos.org | Skype: mkrantz.mifos.org | http://mifos.org > > <http://facebook.com/mifos> <http://www.twitter.com/mifos> > > > -- > Regards, > Ashok > > Sent from mobile device >
