Build a web application before or after deployment?

Question

Context

• The web application project has a /build (or /dist ) folder with front-end files created during build ( Gulp ). This folder is not under source control (see, for example: React.js Starter Kit )
• Server code does not require a build or compilation step, so the /src folder from your project can be expanded as is (these source files are used to run Node.js or ASP.NET vNext server)
• The web application is deployed through Git (see Git deployment options in Heroku or Windows Azure for an example)

Questions

• Is it better to create (combine and minimize) front-end files before or after deployment?
  • If earlier, you can get a separate repository (or branch) with the /build folder under source control along with the rest of the project files. This repo is used solely for deployment purposes.
  • If after this the deployment time can increase - the time required to download additional npm modules used during the build process, the server processor can increase up to 100% during build, which can harm your reaction to the web application.
• Is it better to create front-end files on a remote server before or after the KuduSync command?
• If you deploy your web application to Windows Azure with Kudu , if the deployment script only copies the contents of the /build folder (with public, interface files like .js, .html, .css) - /wwwroot ? Unlike copying all project files (server-side source code and front-end packages) that it runs by default.
• By default, the Azure script deployment copies all project files from the D:\home\site\repository folder to the D:\home\site\wwwroot , and then the Node.js. application starts. Is this a necessary step? Why not launch the Node.js application (or ASP.NET vNext) from the folder D:\home\site\repository ? And if it really needs to be copied to a separate folder, why are the source files placed in wwwroot , maybe it is better to copy them to another folder outside wwwroot ?

Answer 1

I am not familiar with either Azure or Heroku, so I cannot give any idea about these deployment options.

I use (4 dedicated servers with two of them exclusively for working with static files), the ability to create nested and miniature javascript files (for front-end) and add all these files to the main repository has several advantages

• You only need to run it once (either on your development computer or on an intermediate server, whatever you want). This is especially useful when you need to run multiple static servers, since you do not need to run the build command on each server. It can be argued that they can use something like Glusterfs to synchronize files from one static server to all other servers, and the build process needs to be run only once. However, this is a completely different story when it comes to these kinds of settings.
• This simplifies the deployment process, just pulls out the new code and reboots the server if necessary (provided that you have a mechanism to increase the static version of the file so that all your clients get the latest version)
• Avoid unnecessary dependencies on your production servers. This may seem strange to some people, but I just do not want to install any additional libraries on my production servers unless they are absolutely necessary. When the build process runs locally on my dev machine, my production servers have only what they need to run the production code, and nothing else

However, this approach also has some disadvantages:

• When several developers in your team (by accident) start the build process and commit the code, you will have a crazy list of conflicts. However, it can be solved by simply starting the build process again after you merge all the changes from the other guys. This is more about workflow.
• Your repository will be larger. I personally do not think this is a big problem, given the few additional MB of my combined and mini files. If your javascript frontend is big enough to be a problem, then this is another story.