New commits in QA phaseContinuous integration and continuous delivery with git-flowGet Git commit from “upstream” build in manually triggered Jenkins jobJenkins builds when using trunk based developmentJenkins: how to trigger pipeline on git tagRelease Branch and Continuous DeliveryJenkins and GitLab CI integration with Multibranch and individual pipelinesJenkins pipeline plugin - Jenkins as codeTrigger deployment job from Multibranch pipeline JenkinsfileHow to trigger a pipeline execution in QA environment?How many pipelines for Trunk Based Development?

Multi tool use
What could make large expeditions ineffective for exploring territory full of dangers and valuable resources?
What is a Kravchuk transform and how is it related to Fourier transforms?
Should I have shared a document with a former employee?
Who or what determines if a curse is valid or not?
What does "mossette" translate to in English
Are there foods that astronauts are explicitly never allowed to eat?
Why aren't there any women super Grandmasters (GMs)?
Does unblocking power bar outlets through short extension cords increase fire risk?
How to get a type of "screech" on guitar
Found old paper shares of Motorola Inc that has since been broken up
Is it possible to target 2 allies with the Warding Bond spell using the Sorcerer's Twinned Spell metamagic option?
You have no, but can try for yes
Masyu-making game
Project Euler # 25 The 1000 digit Fibonacci index
Why there is no article before venture capital firm in "Beller’s first high-profile role was at venture capital firm Andreessen Horwitz, .."?
Are there any satellites in geosynchronous but not geostationary orbits?
Do pedestrians imitate automotive traffic?
To what extent does asymmetric cryptography secure bitcoin transactions?
Dative single noun Bankautomaten?
Parser for STL stereolithography data files
The most secure way to handle someone forgetting to verify their account?
Did Hitler say this quote about homeschooling?
Get Chord Name From a Given Set of Notes
Improving an O(N^2) function (all entities iterating over all other entities)
New commits in QA phase
Continuous integration and continuous delivery with git-flowGet Git commit from “upstream” build in manually triggered Jenkins jobJenkins builds when using trunk based developmentJenkins: how to trigger pipeline on git tagRelease Branch and Continuous DeliveryJenkins and GitLab CI integration with Multibranch and individual pipelinesJenkins pipeline plugin - Jenkins as codeTrigger deployment job from Multibranch pipeline JenkinsfileHow to trigger a pipeline execution in QA environment?How many pipelines for Trunk Based Development?
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;
Application is currently deployed and tested using Dev pipeline(Jenkins)
source code is in develop
branch on GitLab, following Gitflow workflow
QA pipeline will trigger build, test & deployment after tagging a specific commit in develop
branch, before creating release
branch, as shown below:
As per Git flow, Ideally QA pipeline should trigger on artifact($release_num-$JenkinsBuildNum-SNAPSHOT.jar
) but not on a git commit in develop
branch.
After moving apps to QA space for testing by QA team,
1) Is development team not suppose to create any new commits in develop
branch? Unless QA team discover any bugs
2) What should be the naming convention of artifact generated by QA pipeline? Dev pipeline generates artifact with name $release_num-$JenkinsBuildNum-SNAPSHOT.jar
testing continuous-integration jenkins-pipeline continuous-deployment qa
add a comment |
Application is currently deployed and tested using Dev pipeline(Jenkins)
source code is in develop
branch on GitLab, following Gitflow workflow
QA pipeline will trigger build, test & deployment after tagging a specific commit in develop
branch, before creating release
branch, as shown below:
As per Git flow, Ideally QA pipeline should trigger on artifact($release_num-$JenkinsBuildNum-SNAPSHOT.jar
) but not on a git commit in develop
branch.
After moving apps to QA space for testing by QA team,
1) Is development team not suppose to create any new commits in develop
branch? Unless QA team discover any bugs
2) What should be the naming convention of artifact generated by QA pipeline? Dev pipeline generates artifact with name $release_num-$JenkinsBuildNum-SNAPSHOT.jar
testing continuous-integration jenkins-pipeline continuous-deployment qa
Is QA pipeline artifact should be something like$release_num-$git_tag}-release.jar
– overexchange
Mar 26 at 13:45
add a comment |
Application is currently deployed and tested using Dev pipeline(Jenkins)
source code is in develop
branch on GitLab, following Gitflow workflow
QA pipeline will trigger build, test & deployment after tagging a specific commit in develop
branch, before creating release
branch, as shown below:
As per Git flow, Ideally QA pipeline should trigger on artifact($release_num-$JenkinsBuildNum-SNAPSHOT.jar
) but not on a git commit in develop
branch.
After moving apps to QA space for testing by QA team,
1) Is development team not suppose to create any new commits in develop
branch? Unless QA team discover any bugs
2) What should be the naming convention of artifact generated by QA pipeline? Dev pipeline generates artifact with name $release_num-$JenkinsBuildNum-SNAPSHOT.jar
testing continuous-integration jenkins-pipeline continuous-deployment qa
Application is currently deployed and tested using Dev pipeline(Jenkins)
source code is in develop
branch on GitLab, following Gitflow workflow
QA pipeline will trigger build, test & deployment after tagging a specific commit in develop
branch, before creating release
branch, as shown below:
As per Git flow, Ideally QA pipeline should trigger on artifact($release_num-$JenkinsBuildNum-SNAPSHOT.jar
) but not on a git commit in develop
branch.
After moving apps to QA space for testing by QA team,
1) Is development team not suppose to create any new commits in develop
branch? Unless QA team discover any bugs
2) What should be the naming convention of artifact generated by QA pipeline? Dev pipeline generates artifact with name $release_num-$JenkinsBuildNum-SNAPSHOT.jar
testing continuous-integration jenkins-pipeline continuous-deployment qa
testing continuous-integration jenkins-pipeline continuous-deployment qa
edited Mar 26 at 13:50
overexchange
asked Mar 26 at 11:45
overexchangeoverexchange
4,0867 gold badges33 silver badges90 bronze badges
4,0867 gold badges33 silver badges90 bronze badges
Is QA pipeline artifact should be something like$release_num-$git_tag}-release.jar
– overexchange
Mar 26 at 13:45
add a comment |
Is QA pipeline artifact should be something like$release_num-$git_tag}-release.jar
– overexchange
Mar 26 at 13:45
Is QA pipeline artifact should be something like
$release_num-$git_tag}-release.jar
– overexchange
Mar 26 at 13:45
Is QA pipeline artifact should be something like
$release_num-$git_tag}-release.jar
– overexchange
Mar 26 at 13:45
add a comment |
1 Answer
1
active
oldest
votes
I am not sure if I understand the description of your problem correctly, so im trying to rephrase it:
- You are using some kind of continuous integration and deployment server.
- Your source code is on GitLab.
- Tagging a commit on your
develop
branch will trigger a QA pipeline/build that builds your app from this commit and deploys it to the QA space so the testers can install and test it.
Now, your question seems to be:
Does the development team have to wait ("code freeze") with commiting to the develop
branch until the testers are finished testing?
If you asked what I described above, my answer would be the following:
Try to apply the git flow workflow as your git branching model in the future.
For your current problem, just create another branch from the commit you tagged on your develop
branch and name the branch release
.
Now the developers can keep working on new features as normal and commit their changes to your develop
branch.
If the testers find any bugs that need to be fixed you can do this on the release
branch. When everything is fixed you can build your tested app version from the release branch.
Do not forget to merge the bug fixes you made on your release
branch back to the develop
branch after finishing.
EDIT after clarification of question:
As I see it: Gitflow, if applied correctly, should actually solve exactly the problem you ask about in question 1:
The branch where your day-to-day developer work is added to is develop
. When you reach a point where you implemented everything you want and think you are ready to release something (from your developer point of view) you create the release
branch to have the current version (your release candidate) saved somewhere and let the testers verify this version. You as a developer can just keep on working on the next features and keep commiting your changes to the develop
branch.
When the testers find a bug, you fix the bug on the release
branch. When everything is fixed you can create an app version from the release
branch and release it to the customers. When it is actually released you push your release
branch to the master
branch and also merge your changes on the release
branch back to develop
.
So the release branch exists exactly to avoid your problem 1) as far as I understand.
There is most likely some reason your process works this way, but why create the release
branch after the testers have tested?
we are following Gitflow.release
branch will be created after QA phase says OK.
– overexchange
Mar 26 at 13:26
Query edited.. check it out
– overexchange
Mar 26 at 13:38
add a comment |
Your Answer
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55356355%2fnew-commits-in-qa-phase%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
I am not sure if I understand the description of your problem correctly, so im trying to rephrase it:
- You are using some kind of continuous integration and deployment server.
- Your source code is on GitLab.
- Tagging a commit on your
develop
branch will trigger a QA pipeline/build that builds your app from this commit and deploys it to the QA space so the testers can install and test it.
Now, your question seems to be:
Does the development team have to wait ("code freeze") with commiting to the develop
branch until the testers are finished testing?
If you asked what I described above, my answer would be the following:
Try to apply the git flow workflow as your git branching model in the future.
For your current problem, just create another branch from the commit you tagged on your develop
branch and name the branch release
.
Now the developers can keep working on new features as normal and commit their changes to your develop
branch.
If the testers find any bugs that need to be fixed you can do this on the release
branch. When everything is fixed you can build your tested app version from the release branch.
Do not forget to merge the bug fixes you made on your release
branch back to the develop
branch after finishing.
EDIT after clarification of question:
As I see it: Gitflow, if applied correctly, should actually solve exactly the problem you ask about in question 1:
The branch where your day-to-day developer work is added to is develop
. When you reach a point where you implemented everything you want and think you are ready to release something (from your developer point of view) you create the release
branch to have the current version (your release candidate) saved somewhere and let the testers verify this version. You as a developer can just keep on working on the next features and keep commiting your changes to the develop
branch.
When the testers find a bug, you fix the bug on the release
branch. When everything is fixed you can create an app version from the release
branch and release it to the customers. When it is actually released you push your release
branch to the master
branch and also merge your changes on the release
branch back to develop
.
So the release branch exists exactly to avoid your problem 1) as far as I understand.
There is most likely some reason your process works this way, but why create the release
branch after the testers have tested?
we are following Gitflow.release
branch will be created after QA phase says OK.
– overexchange
Mar 26 at 13:26
Query edited.. check it out
– overexchange
Mar 26 at 13:38
add a comment |
I am not sure if I understand the description of your problem correctly, so im trying to rephrase it:
- You are using some kind of continuous integration and deployment server.
- Your source code is on GitLab.
- Tagging a commit on your
develop
branch will trigger a QA pipeline/build that builds your app from this commit and deploys it to the QA space so the testers can install and test it.
Now, your question seems to be:
Does the development team have to wait ("code freeze") with commiting to the develop
branch until the testers are finished testing?
If you asked what I described above, my answer would be the following:
Try to apply the git flow workflow as your git branching model in the future.
For your current problem, just create another branch from the commit you tagged on your develop
branch and name the branch release
.
Now the developers can keep working on new features as normal and commit their changes to your develop
branch.
If the testers find any bugs that need to be fixed you can do this on the release
branch. When everything is fixed you can build your tested app version from the release branch.
Do not forget to merge the bug fixes you made on your release
branch back to the develop
branch after finishing.
EDIT after clarification of question:
As I see it: Gitflow, if applied correctly, should actually solve exactly the problem you ask about in question 1:
The branch where your day-to-day developer work is added to is develop
. When you reach a point where you implemented everything you want and think you are ready to release something (from your developer point of view) you create the release
branch to have the current version (your release candidate) saved somewhere and let the testers verify this version. You as a developer can just keep on working on the next features and keep commiting your changes to the develop
branch.
When the testers find a bug, you fix the bug on the release
branch. When everything is fixed you can create an app version from the release
branch and release it to the customers. When it is actually released you push your release
branch to the master
branch and also merge your changes on the release
branch back to develop
.
So the release branch exists exactly to avoid your problem 1) as far as I understand.
There is most likely some reason your process works this way, but why create the release
branch after the testers have tested?
we are following Gitflow.release
branch will be created after QA phase says OK.
– overexchange
Mar 26 at 13:26
Query edited.. check it out
– overexchange
Mar 26 at 13:38
add a comment |
I am not sure if I understand the description of your problem correctly, so im trying to rephrase it:
- You are using some kind of continuous integration and deployment server.
- Your source code is on GitLab.
- Tagging a commit on your
develop
branch will trigger a QA pipeline/build that builds your app from this commit and deploys it to the QA space so the testers can install and test it.
Now, your question seems to be:
Does the development team have to wait ("code freeze") with commiting to the develop
branch until the testers are finished testing?
If you asked what I described above, my answer would be the following:
Try to apply the git flow workflow as your git branching model in the future.
For your current problem, just create another branch from the commit you tagged on your develop
branch and name the branch release
.
Now the developers can keep working on new features as normal and commit their changes to your develop
branch.
If the testers find any bugs that need to be fixed you can do this on the release
branch. When everything is fixed you can build your tested app version from the release branch.
Do not forget to merge the bug fixes you made on your release
branch back to the develop
branch after finishing.
EDIT after clarification of question:
As I see it: Gitflow, if applied correctly, should actually solve exactly the problem you ask about in question 1:
The branch where your day-to-day developer work is added to is develop
. When you reach a point where you implemented everything you want and think you are ready to release something (from your developer point of view) you create the release
branch to have the current version (your release candidate) saved somewhere and let the testers verify this version. You as a developer can just keep on working on the next features and keep commiting your changes to the develop
branch.
When the testers find a bug, you fix the bug on the release
branch. When everything is fixed you can create an app version from the release
branch and release it to the customers. When it is actually released you push your release
branch to the master
branch and also merge your changes on the release
branch back to develop
.
So the release branch exists exactly to avoid your problem 1) as far as I understand.
There is most likely some reason your process works this way, but why create the release
branch after the testers have tested?
I am not sure if I understand the description of your problem correctly, so im trying to rephrase it:
- You are using some kind of continuous integration and deployment server.
- Your source code is on GitLab.
- Tagging a commit on your
develop
branch will trigger a QA pipeline/build that builds your app from this commit and deploys it to the QA space so the testers can install and test it.
Now, your question seems to be:
Does the development team have to wait ("code freeze") with commiting to the develop
branch until the testers are finished testing?
If you asked what I described above, my answer would be the following:
Try to apply the git flow workflow as your git branching model in the future.
For your current problem, just create another branch from the commit you tagged on your develop
branch and name the branch release
.
Now the developers can keep working on new features as normal and commit their changes to your develop
branch.
If the testers find any bugs that need to be fixed you can do this on the release
branch. When everything is fixed you can build your tested app version from the release branch.
Do not forget to merge the bug fixes you made on your release
branch back to the develop
branch after finishing.
EDIT after clarification of question:
As I see it: Gitflow, if applied correctly, should actually solve exactly the problem you ask about in question 1:
The branch where your day-to-day developer work is added to is develop
. When you reach a point where you implemented everything you want and think you are ready to release something (from your developer point of view) you create the release
branch to have the current version (your release candidate) saved somewhere and let the testers verify this version. You as a developer can just keep on working on the next features and keep commiting your changes to the develop
branch.
When the testers find a bug, you fix the bug on the release
branch. When everything is fixed you can create an app version from the release
branch and release it to the customers. When it is actually released you push your release
branch to the master
branch and also merge your changes on the release
branch back to develop
.
So the release branch exists exactly to avoid your problem 1) as far as I understand.
There is most likely some reason your process works this way, but why create the release
branch after the testers have tested?
edited Mar 26 at 14:39
answered Mar 26 at 13:25
0xFEFFEFE0xFEFFEFE
9010 bronze badges
9010 bronze badges
we are following Gitflow.release
branch will be created after QA phase says OK.
– overexchange
Mar 26 at 13:26
Query edited.. check it out
– overexchange
Mar 26 at 13:38
add a comment |
we are following Gitflow.release
branch will be created after QA phase says OK.
– overexchange
Mar 26 at 13:26
Query edited.. check it out
– overexchange
Mar 26 at 13:38
we are following Gitflow.
release
branch will be created after QA phase says OK.– overexchange
Mar 26 at 13:26
we are following Gitflow.
release
branch will be created after QA phase says OK.– overexchange
Mar 26 at 13:26
Query edited.. check it out
– overexchange
Mar 26 at 13:38
Query edited.. check it out
– overexchange
Mar 26 at 13:38
add a comment |
Got a question that you can’t ask on public Stack Overflow? Learn more about sharing private information with Stack Overflow for Teams.
Got a question that you can’t ask on public Stack Overflow? Learn more about sharing private information with Stack Overflow for Teams.
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55356355%2fnew-commits-in-qa-phase%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
KfTXBoN6eCaw9OiAytk Im7QW u,3Y0eC 8 K0KeKjLbg 0oC 0Lx7rm1Y
Is QA pipeline artifact should be something like
$release_num-$git_tag}-release.jar
– overexchange
Mar 26 at 13:45