Right way to make deploy to production
up vote
0
down vote
favorite
Symfony documentation says to keep /public/build folder in .gitignore
So when I'm pushing my files, there no build folder on production, so I need to build assets.
But documentation also says that assets need to build on the dev server.
So, I need your advice about the right way to deploy.
1) Push build folder with git?
2) Install yarn, nodeJs on production and deploy after git pull?
Thank you.
git symfony deployment
add a comment |
up vote
0
down vote
favorite
Symfony documentation says to keep /public/build folder in .gitignore
So when I'm pushing my files, there no build folder on production, so I need to build assets.
But documentation also says that assets need to build on the dev server.
So, I need your advice about the right way to deploy.
1) Push build folder with git?
2) Install yarn, nodeJs on production and deploy after git pull?
Thank you.
git symfony deployment
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
Symfony documentation says to keep /public/build folder in .gitignore
So when I'm pushing my files, there no build folder on production, so I need to build assets.
But documentation also says that assets need to build on the dev server.
So, I need your advice about the right way to deploy.
1) Push build folder with git?
2) Install yarn, nodeJs on production and deploy after git pull?
Thank you.
git symfony deployment
Symfony documentation says to keep /public/build folder in .gitignore
So when I'm pushing my files, there no build folder on production, so I need to build assets.
But documentation also says that assets need to build on the dev server.
So, I need your advice about the right way to deploy.
1) Push build folder with git?
2) Install yarn, nodeJs on production and deploy after git pull?
Thank you.
git symfony deployment
git symfony deployment
edited Nov 12 at 21:52
asked Nov 12 at 21:38
Adil
316
316
add a comment |
add a comment |
3 Answers
3
active
oldest
votes
up vote
1
down vote
The second. The 1st one always seemed weird to me, I generally never want to push build files to git, the same way I don't push my vendor dir.
Other than the weirdness, you have dev and prod config for encore too, so you will have to pay attention to olny push prod compilations. (example: source maps)
Another problem is asset versioning (https://symfony.com/doc/current/frontend/encore/versioning.html). Since the file names are changing, you will generate unnecessary elements to the change log. If you are working with a team, this might also generate git conflicts.
add a comment |
up vote
1
down vote
There are 3 ways to do this. (Symfony recommends those.)
1-) You should have a build server. In addition, you could send builded files with scp or tools are which help to move files. (For big and complex projects.)
2-) You could build for production on your development machine and you are supposed to move builded files.
3-) You could install npm or yarn on production machine. But personaly it's unnecessary. This option is the last thing that recommended.
For now, i prefer second option. You are supposed to watch this video :)
https://symfonycasts.com/screencast/webpack-encore/production-build
add a comment |
up vote
0
down vote
I will build files locally and deploy by Ansible.
Thank you all.
add a comment |
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
The second. The 1st one always seemed weird to me, I generally never want to push build files to git, the same way I don't push my vendor dir.
Other than the weirdness, you have dev and prod config for encore too, so you will have to pay attention to olny push prod compilations. (example: source maps)
Another problem is asset versioning (https://symfony.com/doc/current/frontend/encore/versioning.html). Since the file names are changing, you will generate unnecessary elements to the change log. If you are working with a team, this might also generate git conflicts.
add a comment |
up vote
1
down vote
The second. The 1st one always seemed weird to me, I generally never want to push build files to git, the same way I don't push my vendor dir.
Other than the weirdness, you have dev and prod config for encore too, so you will have to pay attention to olny push prod compilations. (example: source maps)
Another problem is asset versioning (https://symfony.com/doc/current/frontend/encore/versioning.html). Since the file names are changing, you will generate unnecessary elements to the change log. If you are working with a team, this might also generate git conflicts.
add a comment |
up vote
1
down vote
up vote
1
down vote
The second. The 1st one always seemed weird to me, I generally never want to push build files to git, the same way I don't push my vendor dir.
Other than the weirdness, you have dev and prod config for encore too, so you will have to pay attention to olny push prod compilations. (example: source maps)
Another problem is asset versioning (https://symfony.com/doc/current/frontend/encore/versioning.html). Since the file names are changing, you will generate unnecessary elements to the change log. If you are working with a team, this might also generate git conflicts.
The second. The 1st one always seemed weird to me, I generally never want to push build files to git, the same way I don't push my vendor dir.
Other than the weirdness, you have dev and prod config for encore too, so you will have to pay attention to olny push prod compilations. (example: source maps)
Another problem is asset versioning (https://symfony.com/doc/current/frontend/encore/versioning.html). Since the file names are changing, you will generate unnecessary elements to the change log. If you are working with a team, this might also generate git conflicts.
edited Nov 13 at 0:27
answered Nov 13 at 0:22
Padam87
87957
87957
add a comment |
add a comment |
up vote
1
down vote
There are 3 ways to do this. (Symfony recommends those.)
1-) You should have a build server. In addition, you could send builded files with scp or tools are which help to move files. (For big and complex projects.)
2-) You could build for production on your development machine and you are supposed to move builded files.
3-) You could install npm or yarn on production machine. But personaly it's unnecessary. This option is the last thing that recommended.
For now, i prefer second option. You are supposed to watch this video :)
https://symfonycasts.com/screencast/webpack-encore/production-build
add a comment |
up vote
1
down vote
There are 3 ways to do this. (Symfony recommends those.)
1-) You should have a build server. In addition, you could send builded files with scp or tools are which help to move files. (For big and complex projects.)
2-) You could build for production on your development machine and you are supposed to move builded files.
3-) You could install npm or yarn on production machine. But personaly it's unnecessary. This option is the last thing that recommended.
For now, i prefer second option. You are supposed to watch this video :)
https://symfonycasts.com/screencast/webpack-encore/production-build
add a comment |
up vote
1
down vote
up vote
1
down vote
There are 3 ways to do this. (Symfony recommends those.)
1-) You should have a build server. In addition, you could send builded files with scp or tools are which help to move files. (For big and complex projects.)
2-) You could build for production on your development machine and you are supposed to move builded files.
3-) You could install npm or yarn on production machine. But personaly it's unnecessary. This option is the last thing that recommended.
For now, i prefer second option. You are supposed to watch this video :)
https://symfonycasts.com/screencast/webpack-encore/production-build
There are 3 ways to do this. (Symfony recommends those.)
1-) You should have a build server. In addition, you could send builded files with scp or tools are which help to move files. (For big and complex projects.)
2-) You could build for production on your development machine and you are supposed to move builded files.
3-) You could install npm or yarn on production machine. But personaly it's unnecessary. This option is the last thing that recommended.
For now, i prefer second option. You are supposed to watch this video :)
https://symfonycasts.com/screencast/webpack-encore/production-build
answered Nov 13 at 13:09
Mert Simsek
806311
806311
add a comment |
add a comment |
up vote
0
down vote
I will build files locally and deploy by Ansible.
Thank you all.
add a comment |
up vote
0
down vote
I will build files locally and deploy by Ansible.
Thank you all.
add a comment |
up vote
0
down vote
up vote
0
down vote
I will build files locally and deploy by Ansible.
Thank you all.
I will build files locally and deploy by Ansible.
Thank you all.
answered Nov 13 at 14:04
Adil
316
316
add a comment |
add a comment |
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%2f53270472%2fright-way-to-make-deploy-to-production%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