Hi Samisa, Having a 'Staging' doesn't seem to solve the problem. let me explain the work flow:
V1.build1 is deployed in Production -> Devops demote v1.build1 to 'Staging' -> Dev ops demote v1.build1 to Testing -> QA demote v1.build1 to Development -> Developer make changes (and make V1.build2) and promotes to Testing -> QA promotes (V1.build2) to Staging (This overwrites V1.build1) -> Devops promote V1.build2 to Production -> V1.build2 Crashes in Production. @Manjula, If users wants have a work flow (or a development process) where one version of the Application in production at any given time, then we don't need multiple builds per version. Because, when V2 of application goes to production, user can retire V1 (if V2 doesn't work then user can still bring V1 to production again, until V2 is fixed) However, If user needs multiple versions in production then this need arises. thoughts? On Thu, Dec 19, 2013 at 3:42 PM, Manjula Rathnayake <[email protected]>wrote: > Hi all, > > Do we need to support v1.build1, v1.build2 like artifacts when we have a > version concept already such as v1, v2 ? It seems to me that, having > v1.build1, v1,build2 introduces another version concept based on build > version on top of v1(source version). > > thank you. > > > On Thu, Dec 19, 2013 at 3:33 PM, Samisa Abeysinghe <[email protected]>wrote: > >> I thought, if we had staging, we have a solution. Because, when v1.build2 >> goes into production, and fails, there is an already running v1.build1 to >> which we can transition smoothly. And v1.build1 is guaranteed to work, as >> that was the version which was in production prior to v1.build2. >> >> This is why I asked the original question, if there is no staging, how do >> we revert in case of failure in build2. >> >> >> Thanks, >> Samisa... >> >> >> Samisa Abeysinghe >> >> Vice President Training >> >> WSO2 Inc. >> http://wso2.com >> >> >> >> On Thu, Dec 19, 2013 at 2:54 PM, Ramith Jayasinghe <[email protected]>wrote: >> >>> Hi Samisa, >>> >>> Having application version v1 in production doesn't effect having v2 >>> also in production. since artifacts of V1 and V2 are two different >>> artifacts ( e.g. myapp-v1.war, myapp-v2.war) that will end up in relevant >>> run time (e.g production app server). In that sense, demoting V2 also >>> doesn't affect V1. >>> >>> How ever, I suspect what's explained above doesn't answer your >>> question. If I understood right, your concern is about how to address the >>> scenario where: >>> >>> "user have a one build of the application version V1 ( lets call it >>> V1.build1) working in Production. and for some reason it was demoted all >>> the way back to 'Development'. Then, >>> >>> Developer makes some changes (V1.build2) -> promotes to Testing -> QA >>> promotes to Production -> now Production have V1.build2 -> V1.build2 >>> doesn't work in production. >>> >>> We don't have a solution for this right now. A way to solve this would >>> be : >>> 1. AF needs to have the ability to store multiple artifacts/builds of >>> the same version in a storage. (and add notes, dates ,against these >>> artifacts to so users can keep track) >>> 2. Users ( /devops) should be able to deploy one of these artifacts in >>> a Production ( we could allow similar functionality of other stages too) >>> through UI. >>> >>> Thoughts? >>> >>> >>> regards, >>> Ramith >>> >>> >>> >>> >>> On Thu, Dec 19, 2013 at 2:05 PM, Samisa Abeysinghe <[email protected]>wrote: >>> >>>> So if we deploy an app into production, v1, then it works, then we >>>> deploy v2 into production and it does not work, how do we revert back to >>>> v1? >>>> >>>> >>>> Thanks, >>>> Samisa... >>>> >>>> >>>> Samisa Abeysinghe >>>> >>>> Vice President Training >>>> >>>> WSO2 Inc. >>>> http://wso2.com >>>> >>>> >>>> >>>> On Thu, Dec 19, 2013 at 1:50 PM, Manjula Rathnayake >>>> <[email protected]>wrote: >>>> >>>>> Hi Samisa, >>>>> >>>>> Sorry for late reply. >>>>> >>>>> On Thu, Dec 19, 2013 at 10:46 AM, Samisa Abeysinghe >>>>> <[email protected]>wrote: >>>>> >>>>>> >>>>>> On Wed, Dec 11, 2013 at 9:25 PM, Samisa Abeysinghe >>>>>> <[email protected]>wrote: >>>>>> >>>>>>> So, no staging right? If yes, then where do we roll back to in CI? >>>>>>> >>>>>> Yes, No staging, but we have the support of adding, removing stages >>>>> by configuring it that way. >>>>> Regarding roll back, if the application is in Production, DevOps can >>>>> roll back to Testing. Here, application will be undeployed from >>>>> Production. >>>>> However, in Testing stage, QA can demote the application without >>>>> undeploying the application to continue testing. >>>>> @Ramith, please share any missed information. >>>>> >>>>> thank you. >>>>> >>>>>> >>>>>> PING, I never got a response for my query. >>>>>> >>>>>> _______________________________________________ >>>>>> Architecture mailing list >>>>>> [email protected] >>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Manjula Rathnayaka >>>>> Software Engineer >>>>> WSO2, Inc. >>>>> Mobile:+94 77 743 1987 >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> [email protected] >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> Ramith Jayasinghe >>> Technical Lead >>> WSO2 Inc., http://wso2.com >>> lean.enterprise.middleware >>> >>> E: [email protected] >>> P: +94 776715671 >>> >>> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Manjula Rathnayaka > Software Engineer > WSO2, Inc. > Mobile:+94 77 743 1987 > -- Ramith Jayasinghe Technical Lead WSO2 Inc., http://wso2.com lean.enterprise.middleware E: [email protected] P: +94 776715671
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
