Context
Web application project has a /build (or /dist) folder with front-end files, generated during build (by Gulp). This folder is not under the source control (see, for example: React.js Starter Kit)
The server-side code doesn't require bundling or compilation step, so the /src folder from your project can be deployed as it is (these source files are used to run Node.js or ASP.NET vNext server)
Web application is deployed via Git (see Git-based deployment options in Heroku or Windows Azure as an example)
Questions
Is it better to build (bundle and minify) front-end files before or after deployment?
If before, you may end-up having a separate repository (or branch), with the /build folder under the source control alongside with the rest of the project files. This repo is used solely for deployment purposes.
If after, the deployment time may increase - time needed to download additional npm modules used in the build process, the server's CPU may spike up to 100% during the build, potentially harming your web application's responsiveness.
Is it better to build front-end files on the remote server before or after running KuduSync command?
If you deploy your web application to Windows Azure with Kudu, should the deployment script copy only the contents of the /build folder (with public, front-end files like .js, .html, .css) to /wwwroot? As opposed to copying all the project files (server-side source code and front-end bundles), which it does by default.
By default Azure's deployment script copies all the project files, from D:\home\site\repository folder to D:\home\site\wwwroot folder, and then Node.js app is started from there. Is it a necessary step? Why not to start the Node.js (or ASP.NET vNext) app from the D:\home\site\repository folder? And if it indeed should be copied to a separate folder, why source files are placed in wwwroot, maybe it's better to copy them to another folder, outside wwwroot?
I am not familiar with both Azure and Heroku so I can't give any ideas about those specific deployment options.
I am using (4 dedicated servers with 2 of them solely for serving static files), the option to build the bundled and minified javascript files (for front-end) and add all those files to the main repository has several advantages
You only need to run it once (either on your dev machine or on staging server, whatever way you want). This is particularly helpful when you have to run multiple static servers since you don't have to run the build command on each server. One might argue that they can use something like Glusterfs to synchronise files from one static server to all other servers and the build process only needs to be run once. However, it is a whole different story when it comes to this kind of setup
It makes your deployment process simple, just pull new code and restart the server(s) if necessary (assuming that you have some mechanism to increase the static file version so that all your clients will receive the latest version)
Avoid unnecessary dependencies on your production servers. This might sound weird for some people but I just don't want to install any extra libraries on my production servers unless they are absolutely necessary. With the build process run locally on my dev machine, my production servers only have what they need to run the production code and nothing else
However this approach also has some disadvantages:
When more than one developer in your team (accidentally) run the build process and commit the code, then you will have a crazy list of conflicts. However, it can be solved by simply running the build process again after you merge all the changes from other guys. This is more about the workflow
Your repository will be bigger. I personally don't think this is a big issue considering few extra MB of my bundled and minified files. If your front-end javascript is big enough for this to be an issue then it is another story
Related
We have a site design that makes use of modules that are developed separately from the master site. Thru reflection, we pick up the modules when the main app starts.
This works fine in local development and on a normal web server. But in the Azure environment when we try to use FTP to deploy the modules to our Azure-hosted site we are unable to because the main Azure deployment is read-only (because it is running from a package).
Is it possible to not have the main site running from a package? Is it acceptable to run it that way?
Is there another way to deploy Dlls to the Azure-hosted site without having them be part of the main site's build and deploy? Ultimately we are trying to avoid rebuilding the main site every time we want to add a module.
our Azure-hosted site we are unable to because the main Azure
deployment is read-only (because it is running from a package).
You could set WEBSITE_RUN_FROM_PACKAGE=0in your app setting to make not read only. WEBSITE_RUN_FROM_PACKAGE=1 is read only.
Is it possible to not have the main site running from a package? Is it
acceptable to run it that way?
You could consider switch your deployment methods to Zip Deploy to make your Azure-hosted site not read only.
Refer to this doc.
What can help in this situation is to build and publish the modules using Azure Artifacts.
There are several approaches please check the best practices page over here:
https://learn.microsoft.com/en-us/azure/devops/artifacts/concepts/best-practices?view=azure-devops
Depending on your approach the build, the release but also local development can use these published modules.
Example
You can for example use a private nuget feed:
Publish the modules from your modules pipeline:
https://learn.microsoft.com/en-us/azure/devops/pipelines/artifacts/nuget?toc=%2Fazure%2Fdevops%2Fartifacts%2Ftoc.json&view=azure-devops&tabs=yaml
Consume these from visual studio:
https://learn.microsoft.com/en-us/azure/devops/artifacts/nuget/consume?view=azure-devops&tabs=windows
And consume them from the website pipeline, this can be a build but also a release if you want to side load them:
https://learn.microsoft.com/en-us/azure/devops/pipelines/packages/nuget-restore?source=recommendations&view=azure-devops
To keep a record of what modules are used in the website, I advise to build or release the website if the modules are changed.
Im trying to test different things on Azure, and i have tried to setup a static webapp.
The github repo consists of nothing really.
These files are pretty much empty. Whenever i push something to the repo, the build triggers, but fails with the error Oryx built the app folder but was unable to determine the location of the app artifacts. Please specify the app artifact location through the Github workflow file.
Im uncertain of what it means with artifacts. This tiny webapp doesnt have any real build or anything
In the azure-static-web-apps-xxxxxx-xxxx-xxxxxxx.yml file the app_artifact_location is " "
Not really sure which artifacts its looking for, or what they are really.
You may want to investigate this Quickstart: Building your first static web app.
To add to this app_artifact_location is the location of the build output directory relative to the app_location. For example, if your application source code is located at /app, and the build script outputs files to the /app/build folder, then set build as the app_artifact_location value.
In step Build and Deploy builds and deploys to your Azure Static Web Apps instance. Under the with section, you can customize these values for your deployment.
Reference: https://learn.microsoft.com/en-gb/azure/static-web-apps/github-actions-workflow
Based on https://learn.microsoft.com/en-us/azure/static-web-apps/overview
Python-based frontends are not supported. Clients are served statically and are browser-based apps. The build system (0ryx) likely unable to determine the framework and is generating the error message you are seeing.
The default web page that is expected is index.html. It looks like you may have misspelled it = index.hmtl
Problem: I have a project with a server (Express Server that handles file uploading and deleting) and client (Front End Create-React-App). The project structure looks like follows:
Root Folder With Server
Client Folder
Each folder has it's own package.json. Server Package.json. Client package.json
I'm trying to build and deploy onto azure however the pipeline hangs on "npm install and build".
It seems like the build succeeds but this phase just hangs. Here is my server.js (the routes are not included) file and yaml file just in case.
I'd appreciate any kind of help. Thank you!
Troubleshooting suggestions:
In the case of ensuring that the code in github is consistent with the local code, if an exception occurs, it is recommended to replace the linux platform and redeploy.
It is recommended to use my suggestion to recreate the repository, and then check the Action status in github.
Sum up:
In general, it is more appropriate to use Linux in azure than windows. For example, Linux supports npx, and may also support other packages and commands.
When the local code can run normally, there is generally no problem when deploying to github, unless there may be modifications, which we have ignored. So make sure the code is consistent.
General correct deployment steps:
First in the portal, make sure to create a web app application (not a static web app), and select the node environment.
Make sure that the sever program can run normally locally. Create a new repository in github.
->git init
->git add.
->git commit -m'init'
->git remote add origin https://github.com/{your name}/newAppname.git
->git push -u origin master
Connect in the Portal's Deployment center.
Then check the status of Action in github.
I am fiddling with heroku to deploy my nodejs based application. The problem is I want to run some pre deployment scripts which contain grunt tasks. These tasks basically minify css and js files and perform some more operations like updating the version of the application in files etc.
The only way that I can think of now is to commit the minified files in the git repo itself and deploy.
This is not a good idea (for me at least) as it unnecessarily maintains revision history of minified files which is a total waste.
Please help.
I've seen people recommending creating a throwaway git branch for deployments. In the second of the above comments: How to deploy node app that uses grunt to heroku.
Personally I prefer to execute a grunt task(s) that packages my app and copies it to a directory outside my source tree/repo. Usually the target directory contains a throwaway git repository that I add to just to be able to do the push to heroku.
My workflow is to do any file processing I need to and then to copy the results to the output directory, skipping unnecessary files, and adding environment specific configurations and artifacts. A series of grunt tasks does this and the final one adds everything to the local reopo, sets the heroku remote (I have several apps on heroku to cover production, staging, and a sandbox usually used to look at old versions of things), and finally doing the push.
I'm employing a production-test server, that is, a test server in the production environment, which is only accessible from my company's network. This is for doing smoke tests and regression tests (for example making sure that our 3rd party web services are accessible), before we actually deploy the project to production (the project is a web site).
We use a Perforce Source Control Server and CruiseControl.Net, and I'd like to configure the CruiseControl to check out our production code to two different file system locations (on our build server) so it can build it twice with different build configurations, i.e. one build configuration for production, one for production-test. Then I'm gonna robocopy the production-test build to the production-test server.
How do I specify multiple checkout directories for "production-test" and "production", without having to create two different branches for it?
Create two separate projects. Use Configuration Preprocessor to extract all common parts into a template and include it twice, changing only the project name, working/artifacts directories and the configuration. That's the simplest and most bulletproof solution.