Skip to content
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 from
Closed

Update .gitignore #1257

wants to merge 1 commit into from

Conversation

@gegere
Copy link
Contributor

@gegere 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.

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
Copy link
Member

@retlehs 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
Copy link
Member

@austinpray 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
Copy link
Member

@JulienMelissas 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
Copy link
Contributor Author

@gegere 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
Copy link
Member

@swalkinshaw 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
Copy link
Contributor Author

@gegere 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
Copy link
Member

@swalkinshaw 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
Copy link

@mAAdhaTTah 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
Copy link
Contributor Author

@gegere 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
Copy link
Member

@austinpray 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
Copy link
Contributor Author

@gegere gegere commented Jan 17, 2015

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

@austinpray
Copy link
Member

@austinpray 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
Copy link
Contributor Author

@gegere 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
Labels
None yet
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

6 participants