Test appears in the CLI add command but it's not working when using the promote command

[rmarpozo]

I don't quite understand why the test environment option is given in the CLI pipelines:add command if it's not supported by the pipelines:promote command. When I promote my app from dev it's promoted to staging ignoring the test environment.

Here is the flow I want to implement

dev -> test -> staging -> prod

Thanks

[appleton]

Hi,

It’s a great point. We’ve been chatting about this internally and we’ll
either kill it in the CLI or support it in dashboard before we call the
feature GA. Do you specifically want this? If so could you elaborate a
little on your use case?

Thanks for the feedback,

Andy

On 19 November 2015 at 12:04, Rubén Martín Pozo notifications@github.com
wrote:

I don't quite understand why the test environment option is given in the
CLI pipelines:add command if it's not supported by the pipelines:promote
command. When I promote my app from dev it's promoted to staging ignoring
the test environment.

Here is the flow I want to implement

dev -> test -> staging -> prod

Thanks

—
Reply to this email directly or view it on GitHub
#15.

[rmarpozo]

Hi, thanks for the quick reply

It's indeed very confusing as it is right now. We are not using Github as our repository host so we cannot take advantage of all the fancy things Github Integration does. We use Cloudbees and Jenkins as our CI engine. We were using the old pipeline plugin without problems and we were very happy with it. To be honest pipeline plugin (the old one) is one of the reasons we are using Heroku right now.

We have a development environment where we deploy the code we're working on for the current sprint. Unit testing is run as part of the build. Then, we have a test environment where our testers run exploratory testing and integration and system tests. This environment is different from dev so developers work doesn't interfere with testers. Basically, dev environment is used to test new features by developers while test environment is used by testers.

Then we have staging. We move the code here at the end of the release (3-4 sprints). Staging is different from test because the database has data coming from the production environment. Here we run compatibility tests. We also use staging (we call it pre production, actually) to test hotfixes as well.

When everything is ready we promote it to production.

We cannot use staging as test because the time frames are different. Some testers are doing compatibility tests for the next release in staging while other testers are testing new features in the test environment.

I really like the freedom the old pipeline plugin gave us. I guess every team has it's own and unique workflow so it seems to me a little bit restrictive having a "work for everyone" solution.

Thanks and I hope our experience will help you make a decision.

[appleton]

Thanks for the detailed explanation - it’s great to have real use cases to
anchor our discussions in reality!

Andy

On 19 November 2015 at 14:20, Rubén Martín Pozo notifications@github.com
wrote:

Hi, thanks for the quick reply

It's indeed very confusing as it is right now. We are not using Github as
our repository host so we cannot take advantage of all the fancy things
Github Integration does. We use Cloudbees and Jenkins as our CI engine. We
were using the old pipeline plugin without problems and we were very happy
with it. To be honest pipeline plugin (the old one) is one of the reasons
we are using Heroku right now.

We have a development environment where we deploy the code we're working
on for the current sprint. Unit testing is run as part of the build. Then,
we have a test environment where our testers run exploratory testing and
integration and system tests. This environment is different from dev so
developers work doesn't interfere with testers. Basically, dev environment
is used to test new features by developers while test environment is used
by testers.

Then we have staging. We move the code here at the end of the release (3-4
sprints). Staging is different from test because the database has data
coming from the production environment. Here we run compatibility tests. We
also use staging (we call it pre production, actually) to test hotfixes as
well.

When everything is ready we promote it to production.

We cannot use staging as test because the time frames are different. Some
testers are doing compatibility tests for the next release in staging while
other testers are testing new features in the test environment.

I really like the freedom the old pipeline plugin gave us. I guess every
team has it's own and unique workflow so it seems to me a little bit
restrictive having a "work for everyone" solution.

Thanks and I hope our experience will help you make a decision.

—
Reply to this email directly or view it on GitHub
#15 (comment)
.