CODEWITHSUNDEEP
gitgruntjsweb-deployment
enpenax
enpenax

Reputation: 1562

Grunt Website Project -- How to deplo or handle dist folder with git

in order to step up my game, I finally wanna make the step into Grunt. Starting slowly, I am mostly interested in the cache buster for now (using grunt-cache-bust by Ben Holland) before I go wild with all the possibilities.

I think I managed to get my head around having all of the awesome optimisation tasks run and creating a dist folder that will contain the final version of the files that can be served.

However, I cannot get my head around handling this folder, when it comes to deployment.

I feel it doesn't really make sense to build the folder on my dev machine, and push that to git. Then, vave my server pull the whole repo and serve that dist folder only.

With continuous integration in mind, shouldn't the server pull the git, run the grunt and serve the dist folder?

But that way my server also needs to have node and grunt installed and running.

Q1 So what is the best practise?

Q2 Which are the common grunt operations you are taking (like building for dev, building for production... )?

Q3 How do big projects handle the use of Grunt?
(I am using Laravel but I haven't deployed it yet.)

Q4 I assume that the node_module should be in my git ignore, right?

Upvotes: 0

Views: 317

Answers (1)

Rachid
Rachid

Reputation: 832

Q4: You should alwayse gitignore node_module, bower_components, .tmp

visit this collection of useful .gitignore templates. you might just find the right one for your environment.

Q3: Grunt scales nicely to use in any size project including large and distributed teams. How you configure your Gruntfile matters though. Take a look at this article

Q2: Most of Grunt's tasks are multi-tasks which means that they can have multiple targets each of which has its own set of configuration options. so you can have tasks that perform one way for one target (dev) and in another way for a second target (dist).

Take your stylesheet for example, while you should compile(sass)/concat/minify your CSS before deploying to prod, you probably want to just compile/concat for dev purposes.

The same thing goes for you JavaScript. In prod, compile(coffeescript)/concat/minify/uglify/mangle while in dev you will just compile(coffeescript)/concat.

Here are some common grunt operations: 

grunt.registerTask('test', [
  'clean:server',
  'concurrent:test',
  'autoprefixer',
  'connect:test',
  'karma'
]);

grunt.registerTask('build', [
  'clean:dist',
  'useminPrepare',
  'concurrent:dist',
  'autoprefixer',
  'concat',
  'copy:dist',
  'cdnify',
  'ngmin',
  'cssmin',
  'uglify',
  'rev',
  'usemin',
  'htmlmin'
]);

grunt.registerTask('default', [
  'jshint',
  'test',
  'build'
]);

Q1: Best practice: "building it locally, commit and push to repo". Why?

1- Cause otherwise you have to have all of these tools (Node, Grunt, Bower, Compass, etc..) installed/maintained on the build server. Bower uses Git to go off and consume packages from Git, compass requires Ruby to be installed. (too many moving parts on the build server, which you may or may not have full control of).

2- What if you didn't have control over your build environment server. (e.g: using AWS, VSO, etc...)

3- Imagine this: you've set a dependency entry in package.json to use the caret(^) prefix or tilde(~) prefix (e.g: ^1.1.5). You've build you project on the server and deployed, everyone is happy.

A few weeks later, one of your teammates checks in his changes, the build runs on the server as planned, but since the latest version of that package is now higher (e.g 1.4.1) you prod is built differently and can no longer support one of the options you've used in your Gruntfile.js. You Prod will either fail or, worst case scenario, continue to work but it's misbehaving. Good luck figuring out what happened.

Although, I'd like to see my server takes care of all builds (for instance; TeamCity has a plugin to support NodeJS). I'm much comfortable, deploying what has been tested instead.

Upvotes: 1

Related Questions