Hi, *Deploying patches *
If we have meta file(/json file) in patch directory can be used as patch meta holder/identification. Each time server start or patch module cycle run we can do not need to add patch over again and again. Patch meta file will have param that is it apply or not for app. *Patch folder structure.* Inside patch folder we can mirror app directory structure and do the patching file. /app ---/includes ---/modules ---/controllers ----------/broken-page.js ----------/index.js ---/patches --------/controllers --------------/broken-page.js or we can store files in any structure inside patch folder (main will be root) and use metafile to locate files in app. This will reduce folder crawling. *Regard dependency* Dependency between jaggery patch and usual patch, we will have to handle it manually. WDYT? On Tue, Feb 18, 2014 at 3:48 PM, Madhuka Udantha <[email protected]> wrote: > > > > On Tue, Feb 18, 2014 at 3:42 PM, Ruchira Wageesha <[email protected]>wrote: > >> >>>> >>> But, if we go with a Jaggery module, then they will have to explicitly >>>> engage/initialize the apps for patching via an init script. >>>> >>> If we follow jaggery module for patching then to apply patch, user have >>> to update/add jaggery config file and init script. It is not much good in >>> IMO >>> If this feature come from jaggery core user only need to add the patch >>> folder. It is bit easy and nice for jaggery app user/Dev. >>> >> Nope Madhuka, that's not what I meant. The complete patching process will >> be implemented as Jaggery module and user's will have to make their apps >> patchable via an init script. i.e. Patching can either be enabled or >> disabled via an init script. After that, you will never need to edit >> anything and patches will be automatically picked and deployed. >> >> +1, > >> As an example, assume you have a module named patcher with an init >> method as below. >> >> var init = function(options) { >> setInterval(function() { >> //lookup patches directory and install new patches >> }, options.interval); >> }; >> >> Then, you can have following in your init script. >> >> var patcher = require('patcher'); >> patcher.init({ >> interval: 10000 >> }); >> >> >>> >>>> WDYT? >>>> >>>> /Ruchira >>>> >>>> >>>> >>>> On Tue, Feb 18, 2014 at 11:17 AM, Chan <[email protected]> wrote: >>>> >>>>> Guys it would be awesome if you can describe how the patch directory >>>>> in the app works (I mean in detail). Then everyone will be clear about it. >>>>> >>>>> Cheers~ >>>>> >>>>> >>>>> On Tue, Feb 18, 2014 at 10:12 AM, Madhuka Udantha <[email protected]>wrote: >>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Feb 17, 2014 at 8:56 PM, Nuwan Bandara <[email protected]>wrote: >>>>>> >>>>>>> Guys whats the verdict on this discussion ? Having a patch directory >>>>>>> within the app seems to be a fine idea, which does not effect the >>>>>>> platform >>>>>>> patching or raise depsyc complications. >>>>>>> >>>>>> "patch directory" was most fine solution that we came across on this >>>>>> thread and also same discussion had in few email threads[1] did not have >>>>>> any conclusion for $subject. I too think $subject is essential for all >>>>>> products that depend on jaggery apps >>>>>> I am +1 for "patch directory" >>>>>> >>>>>> Shall we come to a conclusion and implement this. IMO this is vital >>>>>>> to all the products that has jaggery applications. >>>>>>> >>>>>>> >>>>>> [1] Webapp Patching Strategy @ [email protected] on 4/5/13 >>>>>> >>>>>>> Regards, >>>>>>> /Nuwan >>>>>>> >>>>>>> >>>>>>> On Thu, Jan 30, 2014 at 12:19 AM, Chan <[email protected]> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Thursday, January 30, 2014, Tanya Madurapperuma <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Jan 29, 2014 at 10:49 AM, Chan <[email protected]> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Jan 29, 2014 at 10:43 AM, Chan <[email protected]> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Jan 29, 2014 at 10:25 AM, Madhuka Udantha < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Jan 29, 2014 at 3:27 AM, Nuwan Bandara <[email protected]>wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Tue, Jan 28, 2014 at 1:19 PM, Afkham Azeez <[email protected]>wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Tue, Jan 28, 2014 at 11:06 PM, Nuwan Bandara <[email protected]>wrote: >>>>>>>>> >>>>>>>>> Hi All >>>>>>>>> >>>>>>>>> >>>>>>>>> On Tue, Jan 28, 2014 at 11:33 AM, Manuranga Perera >>>>>>>>> <[email protected]>wrote: >>>>>>>>> >>>>>>>>> The problem ultimately boils down to this common scenario: >>>>>>>>> >>>>>>>>> a) A customer has a Jaggery app in their environment. >>>>>>>>> b) Some UI (images, css, headers, ect.) is customized >>>>>>>>> c) Now they find a bug and ask for a patch >>>>>>>>> >>>>>>>>> >>>>>>>>> +1, the issue here is all others replied here against patching a >>>>>>>>> jaggery app is because you think of a jaggery app as a "hello world" >>>>>>>>> web >>>>>>>>> app. But you should look at the jaggery code in products like APIM / >>>>>>>>> AppFac >>>>>>>>> / UES / ES / MDM. In all these products Jaggery app is the place that >>>>>>>>> has >>>>>>>>> the major business logic. In these products Carbon is just the hosting >>>>>>>>> environment. These are full fledge applications that does all kinds of >>>>>>>>> things, generate meta data, has its own configurations etc, and when >>>>>>>>> we >>>>>>>>> find a minor issue we cannot ask people to replace the entire app and >>>>>>>>> reconfigure every thing from the beginning. >>>>>>>>> >>>>>>>>> Just try the application developers shoes for a moment here and >>>>>>>>> get out of the midleware developer mindset; Imagine we have developed >>>>>>>>> an >>>>>>>>> application and thats our main product. Now how do you fix problems >>>>>>>>> in this >>>>>>>>> product ? will you be shipping new versions of the product always >>>>>>>>> when you >>>>>>>>> find an issue ? If that is the case we will be shipping new versions >>>>>>>>> of AS >>>>>>>>> every day ;) >>>>>>>>> >>>>>>>>> Also when there is a requirement we should not think about how it >>>>>>>>> can be squeezed into the existing model with minimum headache. We >>>>>>>>> should >>>>>>>>> find a comfortable solution for the users not something comfortable to >>>>>>>>> implement. >>>>>>>>> >>>>>>>>> >>>>>>>>> The requirement is to fix bugs in apps. The requirement is not, >>>>>>>>> support patching of webapps. The solution is to update the app >>>>>>>>> through patch file if the app is uses a textual scripting >>>>>>>>> language, or redeploy changed or a new version, if the app is in a >>>>>>>>> compiled/binary/bytecode form. >>>>>>>>> >>>>>>>>> >>>>>>>>> +1, that should work, but we nee >>>>>>>>> >>>>>>>>> AFAIU this solution is not feasible as we have to maintain a >>>>>>>>> separate git repo for each customer. >>>>>>>>> >>>>>>>> As far as I know - we do maintain code bases for customers. Plus >>>>>>>> maintaining git repos for customers is realistically not a hard thing >>>>>>>> to do >>>>>>>> cause everything is scriptable in git. >>>>>>>> >>>>>>>>> It will become an issue when the number of customers grow. And >>>>>>>>> also customers with lesser developer knowledge will face issues in >>>>>>>>> resolving conflicts in merging etc. >>>>>>>>> >>>>>>>> If customers customize our jaggery apps which they will definitely >>>>>>>> do - they will version control it anyway and most probably they will >>>>>>>> use >>>>>>>> git. >>>>>>>> >>>>>>>>> >>>>>>>>> Patches approach is nice but thinking from an Application >>>>>>>>> Developer stand point version controlling is the best way to handle >>>>>>>>> this >>>>>>>>> type of patches. Food for thought I guess. >>>>>>>>> >>>>>>>>> [1] - https://devcenter.heroku.com/articles/git >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Tue, Jan 28, 2014 at 1:37 PM, Afkham Azeez <[email protected]>wrote: >>>>>>>>> >>>>>>>>> Cluster-wide patch distribution will be handle by the Operations >>>>>>>>> Center. >>>>>>>>> >>>>>>>>> Azeez >>>>>>>>> >>>>>>>>> >>>>>>>>> On Tue, Jan 28, 2014 at 12:40 PM, Ruchira Wageesha < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Tanya Madurapperuma >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Chan (Dulitha Wijewantha) >>>>>>>> Software Engineer - Mobile Development >>>>>>>> WSO2Mobile >>>>>>>> Lean.Enterprise.Mobileware >>>>>>>> * ~Email [email protected] <[email protected]>* >>>>>>>> * ~Mobile +94712112165 <%2B94712112165>* >>>>>>>> >>>>>>>> * ~Website dulithawijewantha.com <http://dulithawijewantha.com/> >>>>>>>> * >>>>>>>> >>>>>>>> * ~Blog blog.dulithawijewantha.com >>>>>>>> <http://dulichan.github.io/chan/>* >>>>>>>> * ~Twitter @dulitharw <https://twitter.com/dulitharw>* >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Architecture mailing list >>>>>>>> [email protected] >>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> >>>>>>> >>>>>>> *Thanks & Regards,Nuwan BandaraTechnical Lead; **WSO2 Inc. * >>>>>>> *lean . enterprise . middleware | http://wso2.com >>>>>>> <http://wso2.com> * >>>>>>> >>>>>>> *blog : http://nuwanbando.com <http://nuwanbando.com>; email: >>>>>>> [email protected] <[email protected]>; phone: +1 812 606 7390 >>>>>>> <%2B1%20812%20606%207390> * >>>>>>> <http://www.nuwanbando.com/> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Architecture mailing list >>>>>>> [email protected] >>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> *Madhuka* Udantha >>>>>> Senior Software Engineer >>>>>> Development Technologies >>>>>> WSO2 Inc. : http://wso2.com >>>>>> >>>>>> *Mobile*: +94774066336 >>>>>> *Blog*: http://madhukaudantha.blogspot.com/ >>>>>> >>>>>> _______________________________________________ >>>>>> Architecture mailing list >>>>>> [email protected] >>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Chan (Dulitha Wijewantha) >>>>> Software Engineer - Mobile Development >>>>> WSO2Mobile >>>>> Lean.Enterprise.Mobileware >>>>> * ~Email [email protected] <[email protected]>* >>>>> * ~Mobile +94712112165 <%2B94712112165>* >>>>> >>>>> * ~Website dulithawijewantha.com <http://dulithawijewantha.com/> * >>>>> >>>>> * ~Blog blog.dulithawijewantha.com >>>>> <http://dulichan.github.io/chan/>* >>>>> * ~Twitter @dulitharw <https://twitter.com/dulitharw>* >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> [email protected] >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> >>>> *Ruchira Wageesha**Associate Technical Lead* >>>> *WSO2 Inc. - lean . enterprise . middleware | wso2.com >>>> <http://wso2.com>* >>>> >>>> *email: [email protected] <[email protected]>, blog: >>>> ruchirawageesha.blogspot.com <http://ruchirawageesha.blogspot.com>, >>>> mobile: +94 77 5493444 <%2B94%2077%205493444>* >>>> >>> >>> >>> >>> -- >>> *Madhuka* Udantha >>> Senior Software Engineer >>> Development Technologies >>> WSO2 Inc. : http://wso2.com >>> >>> *Mobile*: +94774066336 >>> *Blog*: http://madhukaudantha.blogspot.com/ >>> >> >> >> >> -- >> >> *Ruchira Wageesha**Associate Technical Lead* >> *WSO2 Inc. - lean . enterprise . middleware | wso2.com <http://wso2.com>* >> >> *email: [email protected] <[email protected]>, blog: >> ruchirawageesha.blogspot.com <http://ruchirawageesha.blogspot.com>, >> mobile: +94 77 5493444 <%2B94%2077%205493444>* >> > > > > -- > *Madhuka* Udantha > Senior Software Engineer > Development Technologies > WSO2 Inc. : http://wso2.com > > *Mobile*: +94774066336 > *Blog*: http://madhukaudantha.blogspot.com/ > -- *Madhuka* Udantha Senior Software Engineer Development Technologies WSO2 Inc. : http://wso2.com *Mobile*: +94774066336 *Blog*: http://madhukaudantha.blogspot.com/
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
