Developing with different versions of dependencies
We are developing a PHP application and multiple module dependencies for it. In development we would like to use dev branches and in production tagged versions.
Problem is that some of those modules depend on each other.
What is the best practice to handle the workflow here?
Because if in the main app we require dev versions everyone has to remember to change it before merging to master.
One solution would be to use a separate composer.json file to developing but I think that wouldn't work with dependencies of dependencies.
To illustrate:
Main app composer.json in develop:
"module_1": "dev-develop",
"module_2": "dev-develop",
In "module_1" composer.json:
"module_3": "dev-develop"
In production main composer.json:
"module_1": "^1.0.0",
"module_2": "^1.0.0",
In "module_1" composer.json:
"module_3": "^1.0.0"
git composer-php
asked Nov 19 '18 at 8:42
praxuspraxus
151214
|
show 1 more comment
We are developing a PHP application and multiple module dependencies for it. In development we would like to use dev branches and in production tagged versions.
Problem is that some of those modules depend on each other.
What is the best practice to handle the workflow here?
Because if in the main app we require dev versions everyone has to remember to change it before merging to master.
One solution would be to use a separate composer.json file to developing but I think that wouldn't work with dependencies of dependencies.
To illustrate:
Main app composer.json in develop:
"module_1": "dev-develop",
"module_2": "dev-develop",
In "module_1" composer.json:
"module_3": "dev-develop"
In production main composer.json:
"module_1": "^1.0.0",
"module_2": "^1.0.0",
In "module_1" composer.json:
"module_3": "^1.0.0"
git composer-php
asked Nov 19 '18 at 8:42
praxuspraxus
151214
One could removecomposer.jsonfrom version control and instead check in the two filescomposer.json-template-developandcomposer.json-template-main.
– Micha Wiedenmann
Nov 19 '18 at 8:44
That's actually not a bad solution. Dunno why I haven't thought of it. If no one comes up with a better solution we'll do this.
– praxus
Nov 19 '18 at 9:25
Could you explain why you developt against dev branches? That sounds like needlessly runnign the risk of having things break once you switch to the release versions. So what's the point?
– sleske
Nov 19 '18 at 9:49
Because the module functionality can only be tested in the main app. So we have to run 'composer update'. And it can't be merged to master and tagged before testing.
– praxus
Nov 19 '18 at 10:10
Ah, I see. Then what about the opposite approach: Keep the dev versions, and only switch to production versions right before release? That's what we did on another project.
– sleske
Nov 19 '18 at 10:24
|
show 1 more comment
We are developing a PHP application and multiple module dependencies for it. In development we would like to use dev branches and in production tagged versions.
Problem is that some of those modules depend on each other.
What is the best practice to handle the workflow here?
Because if in the main app we require dev versions everyone has to remember to change it before merging to master.
One solution would be to use a separate composer.json file to developing but I think that wouldn't work with dependencies of dependencies.
To illustrate:
Main app composer.json in develop:
"module_1": "dev-develop",
"module_2": "dev-develop",
In "module_1" composer.json:
"module_3": "dev-develop"
In production main composer.json:
"module_1": "^1.0.0",
"module_2": "^1.0.0",
In "module_1" composer.json:
"module_3": "^1.0.0"
git composer-php
asked Nov 19 '18 at 8:42
praxuspraxus
151214
We are developing a PHP application and multiple module dependencies for it. In development we would like to use dev branches and in production tagged versions.
Problem is that some of those modules depend on each other.
What is the best practice to handle the workflow here?
Because if in the main app we require dev versions everyone has to remember to change it before merging to master.
One solution would be to use a separate composer.json file to developing but I think that wouldn't work with dependencies of dependencies.
To illustrate:
Main app composer.json in develop:
"module_1": "dev-develop",
"module_2": "dev-develop",
In "module_1" composer.json:
"module_3": "dev-develop"
In production main composer.json:
"module_1": "^1.0.0",
"module_2": "^1.0.0",
In "module_1" composer.json:
"module_3": "^1.0.0"
git composer-php
git composer-php
asked Nov 19 '18 at 8:42
praxuspraxus
151214
asked Nov 19 '18 at 8:42
praxuspraxus
151214
asked Nov 19 '18 at 8:42
praxuspraxus
151214
asked Nov 19 '18 at 8:42
praxuspraxus
151214
asked Nov 19 '18 at 8:42
praxuspraxus
151214
151214
One could removecomposer.jsonfrom version control and instead check in the two filescomposer.json-template-developandcomposer.json-template-main.
– Micha Wiedenmann
Nov 19 '18 at 8:44
That's actually not a bad solution. Dunno why I haven't thought of it. If no one comes up with a better solution we'll do this.
– praxus
Nov 19 '18 at 9:25
Could you explain why you developt against dev branches? That sounds like needlessly runnign the risk of having things break once you switch to the release versions. So what's the point?
– sleske
Nov 19 '18 at 9:49
Because the module functionality can only be tested in the main app. So we have to run 'composer update'. And it can't be merged to master and tagged before testing.
– praxus
Nov 19 '18 at 10:10
Ah, I see. Then what about the opposite approach: Keep the dev versions, and only switch to production versions right before release? That's what we did on another project.
– sleske
Nov 19 '18 at 10:24
|
show 1 more comment
One could removecomposer.jsonfrom version control and instead check in the two filescomposer.json-template-developandcomposer.json-template-main.
– Micha Wiedenmann
Nov 19 '18 at 8:44
That's actually not a bad solution. Dunno why I haven't thought of it. If no one comes up with a better solution we'll do this.
– praxus
Nov 19 '18 at 9:25
Could you explain why you developt against dev branches? That sounds like needlessly runnign the risk of having things break once you switch to the release versions. So what's the point?
– sleske
Nov 19 '18 at 9:49
Because the module functionality can only be tested in the main app. So we have to run 'composer update'. And it can't be merged to master and tagged before testing.
– praxus
Nov 19 '18 at 10:10
Ah, I see. Then what about the opposite approach: Keep the dev versions, and only switch to production versions right before release? That's what we did on another project.
– sleske
Nov 19 '18 at 10:24
One could remove
composer.json from version control and instead check in the two files composer.json-template-develop and composer.json-template-main.– Micha Wiedenmann
Nov 19 '18 at 8:44
One could remove
composer.json from version control and instead check in the two files composer.json-template-develop and composer.json-template-main.– Micha Wiedenmann
Nov 19 '18 at 8:44
That's actually not a bad solution. Dunno why I haven't thought of it. If no one comes up with a better solution we'll do this.
– praxus
Nov 19 '18 at 9:25
That's actually not a bad solution. Dunno why I haven't thought of it. If no one comes up with a better solution we'll do this.
– praxus
Nov 19 '18 at 9:25
Could you explain why you developt against dev branches? That sounds like needlessly runnign the risk of having things break once you switch to the release versions. So what's the point?
– sleske
Nov 19 '18 at 9:49
Could you explain why you developt against dev branches? That sounds like needlessly runnign the risk of having things break once you switch to the release versions. So what's the point?
– sleske
Nov 19 '18 at 9:49
Because the module functionality can only be tested in the main app. So we have to run 'composer update'. And it can't be merged to master and tagged before testing.
– praxus
Nov 19 '18 at 10:10
Because the module functionality can only be tested in the main app. So we have to run 'composer update'. And it can't be merged to master and tagged before testing.
– praxus
Nov 19 '18 at 10:10
Ah, I see. Then what about the opposite approach: Keep the dev versions, and only switch to production versions right before release? That's what we did on another project.
– sleske
Nov 19 '18 at 10:24
Ah, I see. Then what about the opposite approach: Keep the dev versions, and only switch to production versions right before release? That's what we did on another project.
– sleske
Nov 19 '18 at 10:24
|
show 1 more comment
2 Answers
2
active
oldest
votes
One could remove composer.json from version control and instead check in the two files composer.json-template-develop and composer.json-template-main.
Note that this generalizes to all configuration files. It makes the difference between version control and deployment more explicit. It is also recommended by Subversion, quoting the FAQ:
I have a file in my project that every developer must change, but I don't want those local mods to ever be committed. How can I make 'svn commit' ignore the file?
The answer is: don't put that file under version control. Instead, put a template of the file under version control, something like "file.tmpl".
Then, after the initial 'svn checkout', have your users (or your build system) do a normal OS copy of the template to the proper filename, and have users customize the copy. The file is unversioned, so it will never be committed. And if you wish, you can add the file to its parent directory's svn:ignore property, so it doesn't show up as '?' in the 'svn status' command.
answered Nov 19 '18 at 9:27
Micha WiedenmannMicha Wiedenmann
10.3k1364104
add a comment |
I'm going to challenge the premise and say:
Don't do this.
Generally you should try to keep as close to the production release as possible during development. That means testing in an environment that is close to production, using data that is close to production data, and using the versions of dependencies that will be used in production. Any deviation from that increases the risk of missing bugs that are hidden by the deviation.
Sometimes it is inevitable to deviate from production (new version of dependency required for new feature, production data cannot be used due to privacy concerns, etc.), but that is the goal you should strive for.
That said, if you absolutely must have different dependencies during development:
Because if in the main app we require dev versions everyone has to
remember to change it before merging to master.
This seems to indicate you develop features on branches, then merge to master.
If that is the case, then the cleanest solution would be to change to production versions before the merge.
The whole point of having feature branches is to test the code before merging it. Properly testing it requires using the dependencies that will be used on master. So, your merge workflow should be:
- switch versions of dependencies to the "production versions" (you may want to hack up a script to do this if it's a lot of work)
- re-test everything to make sure the switch did not break everything
- merge (no merge conflicts in
composer.jsonbecause it's the same on master)
answered Nov 19 '18 at 9:51
sleskesleske
57.6k26137183
As I mentioned in the comment above - the idea is to test before merging. But functionality of modules (not unit or feature tests) need to be tested in main app and they are required via composer. So the problem is that I don't know how to best manage this without changing required versions all the time and that's a mess.
– praxus
Nov 19 '18 at 10:20
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%2f53371004%2fdeveloping-with-different-versions-of-dependencies%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
One could remove composer.json from version control and instead check in the two files composer.json-template-develop and composer.json-template-main.
Note that this generalizes to all configuration files. It makes the difference between version control and deployment more explicit. It is also recommended by Subversion, quoting the FAQ:
I have a file in my project that every developer must change, but I don't want those local mods to ever be committed. How can I make 'svn commit' ignore the file?
The answer is: don't put that file under version control. Instead, put a template of the file under version control, something like "file.tmpl".
Then, after the initial 'svn checkout', have your users (or your build system) do a normal OS copy of the template to the proper filename, and have users customize the copy. The file is unversioned, so it will never be committed. And if you wish, you can add the file to its parent directory's svn:ignore property, so it doesn't show up as '?' in the 'svn status' command.
answered Nov 19 '18 at 9:27
Micha WiedenmannMicha Wiedenmann
10.3k1364104
add a comment |
One could remove composer.json from version control and instead check in the two files composer.json-template-develop and composer.json-template-main.
Note that this generalizes to all configuration files. It makes the difference between version control and deployment more explicit. It is also recommended by Subversion, quoting the FAQ:
I have a file in my project that every developer must change, but I don't want those local mods to ever be committed. How can I make 'svn commit' ignore the file?
The answer is: don't put that file under version control. Instead, put a template of the file under version control, something like "file.tmpl".
Then, after the initial 'svn checkout', have your users (or your build system) do a normal OS copy of the template to the proper filename, and have users customize the copy. The file is unversioned, so it will never be committed. And if you wish, you can add the file to its parent directory's svn:ignore property, so it doesn't show up as '?' in the 'svn status' command.
answered Nov 19 '18 at 9:27
Micha WiedenmannMicha Wiedenmann
10.3k1364104
add a comment |
One could remove composer.json from version control and instead check in the two files composer.json-template-develop and composer.json-template-main.
Note that this generalizes to all configuration files. It makes the difference between version control and deployment more explicit. It is also recommended by Subversion, quoting the FAQ:
I have a file in my project that every developer must change, but I don't want those local mods to ever be committed. How can I make 'svn commit' ignore the file?
The answer is: don't put that file under version control. Instead, put a template of the file under version control, something like "file.tmpl".
Then, after the initial 'svn checkout', have your users (or your build system) do a normal OS copy of the template to the proper filename, and have users customize the copy. The file is unversioned, so it will never be committed. And if you wish, you can add the file to its parent directory's svn:ignore property, so it doesn't show up as '?' in the 'svn status' command.
answered Nov 19 '18 at 9:27
Micha WiedenmannMicha Wiedenmann
10.3k1364104
One could remove composer.json from version control and instead check in the two files composer.json-template-develop and composer.json-template-main.
Note that this generalizes to all configuration files. It makes the difference between version control and deployment more explicit. It is also recommended by Subversion, quoting the FAQ:
I have a file in my project that every developer must change, but I don't want those local mods to ever be committed. How can I make 'svn commit' ignore the file?
The answer is: don't put that file under version control. Instead, put a template of the file under version control, something like "file.tmpl".
Then, after the initial 'svn checkout', have your users (or your build system) do a normal OS copy of the template to the proper filename, and have users customize the copy. The file is unversioned, so it will never be committed. And if you wish, you can add the file to its parent directory's svn:ignore property, so it doesn't show up as '?' in the 'svn status' command.
answered Nov 19 '18 at 9:27
Micha WiedenmannMicha Wiedenmann
10.3k1364104
edited Nov 19 '18 at 9:32
answered Nov 19 '18 at 9:27
Micha WiedenmannMicha Wiedenmann
10.3k1364104
answered Nov 19 '18 at 9:27
Micha WiedenmannMicha Wiedenmann
10.3k1364104
answered Nov 19 '18 at 9:27
Micha WiedenmannMicha Wiedenmann
10.3k1364104
10.3k1364104
add a comment |
add a comment |
I'm going to challenge the premise and say:
Don't do this.
Generally you should try to keep as close to the production release as possible during development. That means testing in an environment that is close to production, using data that is close to production data, and using the versions of dependencies that will be used in production. Any deviation from that increases the risk of missing bugs that are hidden by the deviation.
Sometimes it is inevitable to deviate from production (new version of dependency required for new feature, production data cannot be used due to privacy concerns, etc.), but that is the goal you should strive for.
That said, if you absolutely must have different dependencies during development:
Because if in the main app we require dev versions everyone has to
remember to change it before merging to master.
This seems to indicate you develop features on branches, then merge to master.
If that is the case, then the cleanest solution would be to change to production versions before the merge.
The whole point of having feature branches is to test the code before merging it. Properly testing it requires using the dependencies that will be used on master. So, your merge workflow should be:
- switch versions of dependencies to the "production versions" (you may want to hack up a script to do this if it's a lot of work)
- re-test everything to make sure the switch did not break everything
- merge (no merge conflicts in
composer.jsonbecause it's the same on master)
answered Nov 19 '18 at 9:51
sleskesleske
57.6k26137183
As I mentioned in the comment above - the idea is to test before merging. But functionality of modules (not unit or feature tests) need to be tested in main app and they are required via composer. So the problem is that I don't know how to best manage this without changing required versions all the time and that's a mess.
– praxus
Nov 19 '18 at 10:20
add a comment |
I'm going to challenge the premise and say:
Don't do this.
Generally you should try to keep as close to the production release as possible during development. That means testing in an environment that is close to production, using data that is close to production data, and using the versions of dependencies that will be used in production. Any deviation from that increases the risk of missing bugs that are hidden by the deviation.
Sometimes it is inevitable to deviate from production (new version of dependency required for new feature, production data cannot be used due to privacy concerns, etc.), but that is the goal you should strive for.
That said, if you absolutely must have different dependencies during development:
Because if in the main app we require dev versions everyone has to
remember to change it before merging to master.
This seems to indicate you develop features on branches, then merge to master.
If that is the case, then the cleanest solution would be to change to production versions before the merge.
The whole point of having feature branches is to test the code before merging it. Properly testing it requires using the dependencies that will be used on master. So, your merge workflow should be:
- switch versions of dependencies to the "production versions" (you may want to hack up a script to do this if it's a lot of work)
- re-test everything to make sure the switch did not break everything
- merge (no merge conflicts in
composer.jsonbecause it's the same on master)
answered Nov 19 '18 at 9:51
sleskesleske
57.6k26137183
As I mentioned in the comment above - the idea is to test before merging. But functionality of modules (not unit or feature tests) need to be tested in main app and they are required via composer. So the problem is that I don't know how to best manage this without changing required versions all the time and that's a mess.
– praxus
Nov 19 '18 at 10:20
add a comment |
I'm going to challenge the premise and say:
Don't do this.
Generally you should try to keep as close to the production release as possible during development. That means testing in an environment that is close to production, using data that is close to production data, and using the versions of dependencies that will be used in production. Any deviation from that increases the risk of missing bugs that are hidden by the deviation.
Sometimes it is inevitable to deviate from production (new version of dependency required for new feature, production data cannot be used due to privacy concerns, etc.), but that is the goal you should strive for.
That said, if you absolutely must have different dependencies during development:
Because if in the main app we require dev versions everyone has to
remember to change it before merging to master.
This seems to indicate you develop features on branches, then merge to master.
If that is the case, then the cleanest solution would be to change to production versions before the merge.
The whole point of having feature branches is to test the code before merging it. Properly testing it requires using the dependencies that will be used on master. So, your merge workflow should be:
- switch versions of dependencies to the "production versions" (you may want to hack up a script to do this if it's a lot of work)
- re-test everything to make sure the switch did not break everything
- merge (no merge conflicts in
composer.jsonbecause it's the same on master)
answered Nov 19 '18 at 9:51
sleskesleske
57.6k26137183
I'm going to challenge the premise and say:
Don't do this.
Generally you should try to keep as close to the production release as possible during development. That means testing in an environment that is close to production, using data that is close to production data, and using the versions of dependencies that will be used in production. Any deviation from that increases the risk of missing bugs that are hidden by the deviation.
Sometimes it is inevitable to deviate from production (new version of dependency required for new feature, production data cannot be used due to privacy concerns, etc.), but that is the goal you should strive for.
That said, if you absolutely must have different dependencies during development:
Because if in the main app we require dev versions everyone has to
remember to change it before merging to master.
This seems to indicate you develop features on branches, then merge to master.
If that is the case, then the cleanest solution would be to change to production versions before the merge.
The whole point of having feature branches is to test the code before merging it. Properly testing it requires using the dependencies that will be used on master. So, your merge workflow should be:
- switch versions of dependencies to the "production versions" (you may want to hack up a script to do this if it's a lot of work)
- re-test everything to make sure the switch did not break everything
- merge (no merge conflicts in
composer.jsonbecause it's the same on master)
answered Nov 19 '18 at 9:51
sleskesleske
57.6k26137183
answered Nov 19 '18 at 9:51
sleskesleske
57.6k26137183
answered Nov 19 '18 at 9:51
sleskesleske
57.6k26137183
answered Nov 19 '18 at 9:51
sleskesleske
57.6k26137183
57.6k26137183
As I mentioned in the comment above - the idea is to test before merging. But functionality of modules (not unit or feature tests) need to be tested in main app and they are required via composer. So the problem is that I don't know how to best manage this without changing required versions all the time and that's a mess.
– praxus
Nov 19 '18 at 10:20
add a comment |
As I mentioned in the comment above - the idea is to test before merging. But functionality of modules (not unit or feature tests) need to be tested in main app and they are required via composer. So the problem is that I don't know how to best manage this without changing required versions all the time and that's a mess.
– praxus
Nov 19 '18 at 10:20
As I mentioned in the comment above - the idea is to test before merging. But functionality of modules (not unit or feature tests) need to be tested in main app and they are required via composer. So the problem is that I don't know how to best manage this without changing required versions all the time and that's a mess.
– praxus
Nov 19 '18 at 10:20
As I mentioned in the comment above - the idea is to test before merging. But functionality of modules (not unit or feature tests) need to be tested in main app and they are required via composer. So the problem is that I don't know how to best manage this without changing required versions all the time and that's a mess.
– praxus
Nov 19 '18 at 10:20
add a comment |
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%2f53371004%2fdeveloping-with-different-versions-of-dependencies%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
One could remove
composer.jsonfrom version control and instead check in the two filescomposer.json-template-developandcomposer.json-template-main.– Micha Wiedenmann
Nov 19 '18 at 8:44
That's actually not a bad solution. Dunno why I haven't thought of it. If no one comes up with a better solution we'll do this.
– praxus
Nov 19 '18 at 9:25
Could you explain why you developt against dev branches? That sounds like needlessly runnign the risk of having things break once you switch to the release versions. So what's the point?
– sleske
Nov 19 '18 at 9:49
Because the module functionality can only be tested in the main app. So we have to run 'composer update'. And it can't be merged to master and tagged before testing.
– praxus
Nov 19 '18 at 10:10
Ah, I see. Then what about the opposite approach: Keep the dev versions, and only switch to production versions right before release? That's what we did on another project.
– sleske
Nov 19 '18 at 10:24