Re: [Architecture] [Appfactory][Resources] Improve resource creation and Application Life cycle Management
Hi Samisa, Sorry for late reply. On Thu, Dec 19, 2013 at 10:46 AM, Samisa Abeysinghe sam...@wso2.com wrote: On Wed, Dec 11, 2013 at 9:25 PM, Samisa Abeysinghe sam...@wso2.comwrote: 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 Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- Manjula Rathnayaka Software Engineer WSO2, Inc. Mobile:+94 77 743 1987 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [Appfactory][Resources] Improve resource creation and Application Life cycle Management
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 manju...@wso2.comwrote: Hi Samisa, Sorry for late reply. On Thu, Dec 19, 2013 at 10:46 AM, Samisa Abeysinghe sam...@wso2.comwrote: On Wed, Dec 11, 2013 at 9:25 PM, Samisa Abeysinghe sam...@wso2.comwrote: 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 Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- Manjula Rathnayaka Software Engineer WSO2, Inc. Mobile:+94 77 743 1987 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [Appfactory][Resources] Improve resource creation and Application Life cycle Management
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 sam...@wso2.com 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 manju...@wso2.comwrote: Hi Samisa, Sorry for late reply. On Thu, Dec 19, 2013 at 10:46 AM, Samisa Abeysinghe sam...@wso2.comwrote: On Wed, Dec 11, 2013 at 9:25 PM, Samisa Abeysinghe sam...@wso2.comwrote: 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 Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- Manjula Rathnayaka Software Engineer WSO2, Inc. Mobile:+94 77 743 1987 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- Ramith Jayasinghe Technical Lead WSO2 Inc., http://wso2.com lean.enterprise.middleware E: ram...@wso2.com P: +94 776715671 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [Appfactory][Resources] Improve resource creation and Application Life cycle Management
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 sam...@wso2.com 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 ram...@wso2.comwrote: 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 sam...@wso2.comwrote: 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 manju...@wso2.comwrote: Hi Samisa, Sorry for late reply. On Thu, Dec 19, 2013 at 10:46 AM, Samisa Abeysinghe sam...@wso2.comwrote: On Wed, Dec 11, 2013 at 9:25 PM, Samisa Abeysinghe sam...@wso2.comwrote: 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 Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- Manjula Rathnayaka Software Engineer WSO2, Inc. Mobile:+94 77 743 1987 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- Ramith Jayasinghe Technical Lead WSO2 Inc., http://wso2.com lean.enterprise.middleware E: ram...@wso2.com P: +94 776715671 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- Manjula Rathnayaka Software Engineer WSO2, Inc. Mobile:+94 77 743 1987 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [Appfactory][Resources] Improve resource creation and Application Life cycle Management
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 manju...@wso2.comwrote: 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 sam...@wso2.comwrote: 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 ram...@wso2.comwrote: 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 sam...@wso2.comwrote: 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 manju...@wso2.comwrote: Hi Samisa, Sorry for late reply. On Thu, Dec 19, 2013 at 10:46 AM, Samisa Abeysinghe sam...@wso2.comwrote: On Wed, Dec 11, 2013 at 9:25 PM, Samisa Abeysinghe sam...@wso2.comwrote: 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 Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- Manjula Rathnayaka Software Engineer WSO2, Inc. Mobile:+94 77 743 1987 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- Ramith Jayasinghe Technical Lead WSO2 Inc., http://wso2.com
Re: [Architecture] [Appfactory][Resources] Improve resource creation and Application Life cycle Management
The question is about promoting and demoting build2. For build1 if we deploy and that fails, there is no such scenario of service continuation as there was no service to start with. Thanks, Samisa... Samisa Abeysinghe Vice President Training WSO2 Inc. http://wso2.com On Thu, Dec 19, 2013 at 3:53 PM, Ramith Jayasinghe ram...@wso2.com wrote: 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 manju...@wso2.comwrote: 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 sam...@wso2.comwrote: 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 ram...@wso2.comwrote: 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 sam...@wso2.comwrote: 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 manju...@wso2.com wrote: Hi Samisa, Sorry for late reply. On Thu, Dec 19, 2013 at 10:46 AM, Samisa Abeysinghe sam...@wso2.comwrote: On Wed, Dec 11, 2013 at 9:25 PM, Samisa Abeysinghe sam...@wso2.comwrote: 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 Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- Manjula Rathnayaka Software Engineer WSO2, Inc. Mobile:+94 77 743 1987
Re: [Architecture] [Appfactory][Resources] Improve resource creation and Application Life cycle Management
So, no staging right? If yes, then where do we roll back to in CI? Thanks, Samisa... Samisa Abeysinghe Vice President Training WSO2 Inc. http://wso2.com On Wed, Dec 11, 2013 at 9:40 AM, Manjula Rathnayake manju...@wso2.comwrote: Hi Ushani, See the comments inline, On Wed, Dec 11, 2013 at 9:21 AM, Ushani Balasooriya ush...@wso2.comwrote: Hi Ramith, Just need small clarifications for the questions below. 1) Is it the same when it comes to governance/life cycle management? As in if we promote an app version from Development to Testing, does it mean that app version will not be deployed in the proceeding environment? E.g., Testing Lify cycle change is same as before. application get promoted to next stage. But application does not get auto deployed in Testing until QA(authorized person in QA stage) login and click on 'configure and deploy' button. Currently there is not configuring option allowed to QA person, resources are copied from Development stage. QA person can edit the values of resources as it was before. However, based on user experience, we might give a wizard like user interface to configure all the dependecies used by this application.(This is not M10 feature) 2) If so, user will have to build and deploy the app version in the new stage before they test? No. In test stage, no build is triggered. 3) therefore the Repo and Build page should be available for Test users and Dev Ops as well? No. 4) So when a test user promote an the app version to Production, it does not mean that it will be deployed in Production untill Dev Ops really do it and it will be just a stage change, Am I correct? Yes. Regards, On Tue, Dec 10, 2013 at 8:57 PM, Harsha Thirimanna hars...@wso2.comwrote: As I remember there was another one point in the discussion, When we promoting the artifact , we can do the deployment, resource and database creation at the same time if the logged user has permission to the both stages. I am not sure we are doing it right now. ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *Ushani Balasooriya* Software Engineer - QA; WSO2 Inc; http://www.wso2.com/. Mobile; +94772636796 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture thank you. -- Manjula Rathnayaka Software Engineer WSO2, Inc. Mobile:+94 77 743 1987 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [Appfactory][Resources] Improve resource creation and Application Life cycle Management
As I remember there was another one point in the discussion, When we promoting the artifact , we can do the deployment, resource and database creation at the same time if the logged user has permission to the both stages. I am not sure we are doing it right now. ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [Appfactory][Resources] Improve resource creation and Application Life cycle Management
Hi Ramith, Just need small clarifications for the questions below. 1) Is it the same when it comes to governance/life cycle management? As in if we promote an app version from Development to Testing, does it mean that app version will not be deployed in the proceeding environment? E.g., Testing 2) If so, user will have to build and deploy the app version in the new stage before they test? 3) therefore the Repo and Build page should be available for Test users and Dev Ops as well? 4) So when a test user promote an the app version to Production, it does not mean that it will be deployed in Production untill Dev Ops really do it and it will be just a stage change, Am I correct? Regards, On Tue, Dec 10, 2013 at 8:57 PM, Harsha Thirimanna hars...@wso2.com wrote: As I remember there was another one point in the discussion, When we promoting the artifact , we can do the deployment, resource and database creation at the same time if the logged user has permission to the both stages. I am not sure we are doing it right now. ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *Ushani Balasooriya* Software Engineer - QA; WSO2 Inc; http://www.wso2.com/. Mobile; +94772636796 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [Appfactory][Resources] Improve resource creation and Application Life cycle Management
Hi Ushani, See the comments inline, On Wed, Dec 11, 2013 at 9:21 AM, Ushani Balasooriya ush...@wso2.com wrote: Hi Ramith, Just need small clarifications for the questions below. 1) Is it the same when it comes to governance/life cycle management? As in if we promote an app version from Development to Testing, does it mean that app version will not be deployed in the proceeding environment? E.g., Testing Lify cycle change is same as before. application get promoted to next stage. But application does not get auto deployed in Testing until QA(authorized person in QA stage) login and click on 'configure and deploy' button. Currently there is not configuring option allowed to QA person, resources are copied from Development stage. QA person can edit the values of resources as it was before. However, based on user experience, we might give a wizard like user interface to configure all the dependecies used by this application.(This is not M10 feature) 2) If so, user will have to build and deploy the app version in the new stage before they test? No. In test stage, no build is triggered. 3) therefore the Repo and Build page should be available for Test users and Dev Ops as well? No. 4) So when a test user promote an the app version to Production, it does not mean that it will be deployed in Production untill Dev Ops really do it and it will be just a stage change, Am I correct? Yes. Regards, On Tue, Dec 10, 2013 at 8:57 PM, Harsha Thirimanna hars...@wso2.comwrote: As I remember there was another one point in the discussion, When we promoting the artifact , we can do the deployment, resource and database creation at the same time if the logged user has permission to the both stages. I am not sure we are doing it right now. ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *Ushani Balasooriya* Software Engineer - QA; WSO2 Inc; http://www.wso2.com/. Mobile; +94772636796 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture thank you. -- Manjula Rathnayaka Software Engineer WSO2, Inc. Mobile:+94 77 743 1987 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [Appfactory][Resources] Improve resource creation and Application Life cycle Management
Hi Harsha, my suggestion would be keep the behaviour consistent ( by not auto deploying and copying resources even if the user has permission to both stages). Reasons: 1. This might confuse the users. 2. in my view having access to multiple stages is a rare situation. regards Ramith. On Tue, Dec 10, 2013 at 8:57 PM, Harsha Thirimanna hars...@wso2.com wrote: As I remember there was another one point in the discussion, When we promoting the artifact , we can do the deployment, resource and database creation at the same time if the logged user has permission to the both stages. I am not sure we are doing it right now. ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- Ramith Jayasinghe Technical Lead WSO2 Inc., http://wso2.com lean.enterprise.middleware E: ram...@wso2.com P: +94 776715671 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
