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
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
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
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
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)
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
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,
Hi
We will be changing the behaviour on how resources/data-sources will be
created in each stages.
Current behaviour is that when a user ( - a Developer) with relevant
permission creates an resource/datasource it will be created in all stages.
Relevant users needs to modify the values for each
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.
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
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
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
12 matches
Mail list logo
