Chapter 10 ■ Deployment ConsiDerationsThere is a lot going on in this file and, if you haven’t used Grunt before, you will almost certainly need to follow
a decent tutorial to get at the finer details. However, the main things to observe are that in the first part of the script
(commented as Part One), a set of tasks is configured. In the second part (commented as Part Two), those tasks are
loaded and made ready for use on the command line. Now, assuming we have Grunt installed, we can start Grunt and
enter the grunt command. Grunt will then proceed to perform a number of tasks on our behalf. It will:
• Start to monitor files and directories for changes (the grunt-contrib-watch task).• Minify and bundle our source code files when they change (the grunt-contrib-uglify task).• Copy our source code files and any assets into a distribution folder ready for deployment
(the grunt-contrib-copy task).In this particular script, it is the grunt-contrib-watch task that is started when we launch Grunt, as we made
it the default task. Should this task observe any changes within the configured directories, it will in turn run the
grunt-contrib-minify and grunt-contrib-copy tasks. The end result is a batch of processed files that are placed in
an output directory ready for us to deploy. Though not used here, there are even Grunt tasks that can handle that step
for us too!
You could learn to use a task runner such as Grunt or Gulp in about half a day or so, perhaps even less. Tools
like this really can change your workflow in amazing ways. If you find that you have reached a point where you are
manually performing lots of tasks, you should seriously consider looking into adopting a task runner.
You can learn much more about Grunt at http://gruntjs.com/. Gulp takes a slightly different approach, but it is
essentially the same kind of tool with a similar, perhaps lower, learning curve. You can find more information on Gulp
at http://gulpjs.com/.
Deployment
Deployment is all of the activities that make a software system available for use. As with most of the other things
we have touched upon in this chapter, the implementation details can vary wildly from project to project and
organization to organization.
For many developers, gone are the days where a simple FTP connection to a remote server was all that was
needed in order to transfer files from your local machine to a production environment. For small websites this is still a
valid approach in some cases. However, because web development projects are becoming increasingly more complex,
the teams that work on them need ways to manage this.
If you look at the diagram in Figure 1 0-2 you will see a typical FTP approach to deployment. FTP, or File Transfer
Protocol, is a time tested and reliable means of moving files from one network location to another. The chances are
high that have used FTP before or have some basic understanding of what it is used for. Here the developer has opened
an FTP connection (using an FTP client such as FileZilla or cuteFTP) and used it to transfer code and assets from her
machine to the remote server. At this point the website (or changes to an existing website) is available to the end users.