New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update .gitignore #1257

Closed
wants to merge 1 commit into
base: 8.0.0
from

Conversation

Projects
None yet
6 participants
@gegere
Contributor

gegere commented Jan 15, 2015

Remove dist folder from .gitignore

Ignoring the dist folder would not be good since this is the location for any files processed via gulp.

Update .gitignore
Remove `dist` folder from `.gitignore`

Ignoring the `dist` folder would not be good since this is the location for any files processed via gulp.
@retlehs

This comment has been minimized.

Show comment
Hide comment
@retlehs

retlehs Jan 15, 2015

Member

no

Sent from my iPhone

On Jan 15, 2015, at 4:53 PM, Jason Gegere notifications@github.com wrote:

Remove dist folder from .gitignore

Ignoring the dist folder would not be good since this is the location for any files processed via gulp.

You can merge this Pull Request by running

git pull https://github.com/gegere/roots patch-2
Or view, comment on, or merge it at:

#1257

Commit Summary

Update .gitignore
File Changes

M .gitignore (1)
Patch Links:

https://github.com/roots/roots/pull/1257.patch
https://github.com/roots/roots/pull/1257.diff

Reply to this email directly or view it on GitHub.

Member

retlehs commented Jan 15, 2015

no

Sent from my iPhone

On Jan 15, 2015, at 4:53 PM, Jason Gegere notifications@github.com wrote:

Remove dist folder from .gitignore

Ignoring the dist folder would not be good since this is the location for any files processed via gulp.

You can merge this Pull Request by running

git pull https://github.com/gegere/roots patch-2
Or view, comment on, or merge it at:

#1257

Commit Summary

Update .gitignore
File Changes

M .gitignore (1)
Patch Links:

https://github.com/roots/roots/pull/1257.patch
https://github.com/roots/roots/pull/1257.diff

Reply to this email directly or view it on GitHub.

@austinpray

This comment has been minimized.

Show comment
Hide comment
@austinpray

austinpray Jan 15, 2015

Member

The dist folder is where all the compiled files go.

So two reasons why this is in the gitignore:

  • You are not supposed to check compiled files into source control. This would make it very hard to merge branches among other things.
  • The idea is that you either compile your theme on the server as a part of the deploy process or just upload the dist folder
Member

austinpray commented Jan 15, 2015

The dist folder is where all the compiled files go.

So two reasons why this is in the gitignore:

  • You are not supposed to check compiled files into source control. This would make it very hard to merge branches among other things.
  • The idea is that you either compile your theme on the server as a part of the deploy process or just upload the dist folder

@austinpray austinpray closed this Jan 15, 2015

@JulienMelissas

This comment has been minimized.

Show comment
Hide comment
@JulienMelissas

JulienMelissas Jan 15, 2015

Member

^ what he said, you COULD put it into your source control if it's how you deploy, but we don't recommend it, which is why it's not there by default.

Member

JulienMelissas commented Jan 15, 2015

^ what he said, you COULD put it into your source control if it's how you deploy, but we don't recommend it, which is why it's not there by default.

@gegere

This comment has been minimized.

Show comment
Hide comment
@gegere

gegere Jan 15, 2015

Contributor

Interesting development flow:

  • You would compile the dist files on a LIVE server? This seems like many other files would be needed on the server. Deploy completed code not all the logic needing to build the final files.
  • Merging branches would not be a challenge as the dist folder can be blown away at anytime. Simply rebuild and commit the updated dist js and css.
  • I have always version controlled dist and and pushed changes to LIVE servers, trying to keep the servers as lite as possible.

I think I understand in the terms of the Sage / Theme development the 'dist' folder should not be ignored.

Contributor

gegere commented Jan 15, 2015

Interesting development flow:

  • You would compile the dist files on a LIVE server? This seems like many other files would be needed on the server. Deploy completed code not all the logic needing to build the final files.
  • Merging branches would not be a challenge as the dist folder can be blown away at anytime. Simply rebuild and commit the updated dist js and css.
  • I have always version controlled dist and and pushed changes to LIVE servers, trying to keep the servers as lite as possible.

I think I understand in the terms of the Sage / Theme development the 'dist' folder should not be ignored.

@swalkinshaw

This comment has been minimized.

Show comment
Hide comment
@swalkinshaw

swalkinshaw Jan 15, 2015

Member

@gegere you don't need to compile server-side. You can do it all locally and then upload that folder.

Regardless, it should not be committed to source control. In general, any output of a "build process" should not be committed to source control. Only the original source files should, not compiled outputs.

Member

swalkinshaw commented Jan 15, 2015

@gegere you don't need to compile server-side. You can do it all locally and then upload that folder.

Regardless, it should not be committed to source control. In general, any output of a "build process" should not be committed to source control. Only the original source files should, not compiled outputs.

@gegere

This comment has been minimized.

Show comment
Hide comment
@gegere

gegere Jan 15, 2015

Contributor

Local would be ideal.

Ok my head is starting to hurt. I have a site running on 10 servers and the recommendation is to not commit the built files to a source control? But then I should upload that folder on these servers...?

Please explain more...

Contributor

gegere commented Jan 15, 2015

Local would be ideal.

Ok my head is starting to hurt. I have a site running on 10 servers and the recommendation is to not commit the built files to a source control? But then I should upload that folder on these servers...?

Please explain more...

@swalkinshaw

This comment has been minimized.

Show comment
Hide comment
@swalkinshaw

swalkinshaw Jan 15, 2015

Member

There's nothing much more to explain... it completely depends on your deployment process. You either:

  1. Have your remote servers compile your assets during the deployment.
  2. Locally compile assets during deployment and then scp/whatever the assets to the remote servers.
  3. Ignore a "good practice" and just commit your build files to Git.

You can go ahead and do the last one if you want. We just won't modify our .gitignore by default.

Member

swalkinshaw commented Jan 15, 2015

There's nothing much more to explain... it completely depends on your deployment process. You either:

  1. Have your remote servers compile your assets during the deployment.
  2. Locally compile assets during deployment and then scp/whatever the assets to the remote servers.
  3. Ignore a "good practice" and just commit your build files to Git.

You can go ahead and do the last one if you want. We just won't modify our .gitignore by default.

@mAAdhaTTah

This comment has been minimized.

Show comment
Hide comment
@mAAdhaTTah

mAAdhaTTah Jan 15, 2015

Just to throw it out there, what I do with my theme is compile to a .zip for each release, which is pulled in on each deploy. Kind of a version of @swalkinshaw's 2. See here:

https://github.com/mAAdhaTTah/socialwindow/releases

It also wouldn't be that hard to install node on those servers and just run npm install && gulp/grunt build (or whatever your commands are) on the server after deployment.

mAAdhaTTah commented Jan 15, 2015

Just to throw it out there, what I do with my theme is compile to a .zip for each release, which is pulled in on each deploy. Kind of a version of @swalkinshaw's 2. See here:

https://github.com/mAAdhaTTah/socialwindow/releases

It also wouldn't be that hard to install node on those servers and just run npm install && gulp/grunt build (or whatever your commands are) on the server after deployment.

@gegere

This comment has been minimized.

Show comment
Hide comment
@gegere

gegere Jan 16, 2015

Contributor

@swalkinshaw awesome! This is helpful. I never read or heard about this type of work flow, ignoring the build dir in a production repo.

I'm going to research this a little more. I am starting to think about having a separate build branch. I'll ponder this flow a bit.

Contributor

gegere commented Jan 16, 2015

@swalkinshaw awesome! This is helpful. I never read or heard about this type of work flow, ignoring the build dir in a production repo.

I'm going to research this a little more. I am starting to think about having a separate build branch. I'll ponder this flow a bit.

@austinpray

This comment has been minimized.

Show comment
Hide comment
@austinpray

austinpray Jan 16, 2015

Member

Expanding on what @swalkinshaw was saying while adding some recommendations from my personal experience:

In General

  • Never commit compiled files to source control.
  • Deployments are completely automated
  • Ideally Dev matches Production exactly

Locally compile and upload assets

As a part of your deployment process:

  • build project
  • copy compiled files to remote

Easy peasy.

Where this falls apart

  • No single source of truth: When you have multiple people deploying and compiling there is a lack of "single source of truth". When working on a team or when you hand off a project you run the risk of differences in particular developer's setup causing differences in the compiled files output. This doesn't happen often if you are diligent about locking down versions, but when it does it is extremely frustrating and expensive. It amounts to a ping-pong of intermittent issues based on who is actually deploying.
  • Everyone Requires Credentials: Anyone who needs to deploy has to have access credentials for the server. This requires discipline and lots of work to keep credentials from floating around in the wild.
  • Uploading is slow: Relatively speaking, uploading a bunch of files, especially over SCP, is slow.

Compile on the server

As a part of your provisioning process:

  • Install build dependencies (Node)

As a part of your deployment process:

  • update and prune project dependencies
  • trigger the build

The server is the single source of truth.

Where this falls apart

  • Everyone Requires Credentials
  • Additional Dependencies Required on Application Server: If you have a super duper large build process this can steal resources from app for the duration of the build process.

Continuous Integration

Use something like http://jenkins-ci.org/ or a hosted solution ($$$Travis$$$) to listen for commits. When a commit happens:

  • Run deploy from CI Server
  • CI Server compiles and uploads assets

So:

  • Continuous integration server becomes the single source of truth
  • Developers only need access to the source code
  • Discipline is enforced by CI server so builds human error is not a thing

Where this falls apart

This doesn't fall apart, but is definitely only worth it in the case of:

  • Team environment
  • Long-lived project
  • Continuous development
Member

austinpray commented Jan 16, 2015

Expanding on what @swalkinshaw was saying while adding some recommendations from my personal experience:

In General

  • Never commit compiled files to source control.
  • Deployments are completely automated
  • Ideally Dev matches Production exactly

Locally compile and upload assets

As a part of your deployment process:

  • build project
  • copy compiled files to remote

Easy peasy.

Where this falls apart

  • No single source of truth: When you have multiple people deploying and compiling there is a lack of "single source of truth". When working on a team or when you hand off a project you run the risk of differences in particular developer's setup causing differences in the compiled files output. This doesn't happen often if you are diligent about locking down versions, but when it does it is extremely frustrating and expensive. It amounts to a ping-pong of intermittent issues based on who is actually deploying.
  • Everyone Requires Credentials: Anyone who needs to deploy has to have access credentials for the server. This requires discipline and lots of work to keep credentials from floating around in the wild.
  • Uploading is slow: Relatively speaking, uploading a bunch of files, especially over SCP, is slow.

Compile on the server

As a part of your provisioning process:

  • Install build dependencies (Node)

As a part of your deployment process:

  • update and prune project dependencies
  • trigger the build

The server is the single source of truth.

Where this falls apart

  • Everyone Requires Credentials
  • Additional Dependencies Required on Application Server: If you have a super duper large build process this can steal resources from app for the duration of the build process.

Continuous Integration

Use something like http://jenkins-ci.org/ or a hosted solution ($$$Travis$$$) to listen for commits. When a commit happens:

  • Run deploy from CI Server
  • CI Server compiles and uploads assets

So:

  • Continuous integration server becomes the single source of truth
  • Developers only need access to the source code
  • Discipline is enforced by CI server so builds human error is not a thing

Where this falls apart

This doesn't fall apart, but is definitely only worth it in the case of:

  • Team environment
  • Long-lived project
  • Continuous development
@gegere

This comment has been minimized.

Show comment
Hide comment
@gegere

gegere Jan 17, 2015

Contributor

@austinpray awesome job, thanks for taking the time to expand on this. Very helpful!

Contributor

gegere commented Jan 17, 2015

@austinpray awesome job, thanks for taking the time to expand on this. Very helpful!

@austinpray

This comment has been minimized.

Show comment
Hide comment
@austinpray

austinpray Jan 28, 2015

Member

Made a really tryhard article out of the above wall of text: http://austinpray.com/ops/2015/01/15/build-steps-and-deployment.html

Member

austinpray commented Jan 28, 2015

Made a really tryhard article out of the above wall of text: http://austinpray.com/ops/2015/01/15/build-steps-and-deployment.html

@gegere

This comment has been minimized.

Show comment
Hide comment
@gegere

gegere Jan 28, 2015

Contributor

A really "tryhead" article indeed. Nice write up, lengthy and detailed.

Contributor

gegere commented Jan 28, 2015

A really "tryhead" article indeed. Nice write up, lengthy and detailed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment