My application is based on node.js, and uses bower.js and others task runners to compile assets and build the actual assets (minify, concat, inject...).
Since this is my first application that will be running in a scalable enviroment on Heroku, I was wondering how is the process of deploying.
I mean, my current workflow is:
cd myRepo
git commit [blabla...]
git push heroku
And when running it, it runs npm run wich calls geddy and runs the server.
If I build before pushing, there will be files that are kind of redundant, but if I push the unbuilt project, it should build it on the cloud. Is that the main idea?
Thanks
it should build it on the cloud. Is that the main idea?
Correct; checkout the Dev Center for more Nodejs information:
Heroku Dev Center: Getting Started with Nodejs
Specifically here, it lists information on bower:
Heroku Node.js Support: Customizing the Build Process
Related
How should I setup my dist build and production deployment workflow for my Node.js server app? (NestJS API)?
My current workflow:
Commit changes to production branch
Production server with pm2 automatically pull changes from this repo
Automatic npm install on prod server.
Automatic npm run build on prod server.
Automatic pm2 start on prod server.
The main problem I see in this workflow is that I am running build on production server. This means that I need all devDependencies on server and also I am doing performance spikes on server when building.
I already configured GitHub Actions on my repo to build my code and save it as artifact on commit, but now I am stuck.
Should I commit built source code to repo and then use pm2 hook on production?
Should I download artifact by some script to production, unpack it and run it? I see few problems here:
/dist folder (artifact) does not have package.json and assets
I lost Git functionality, so I need to always delete old source and unpack new source
I don't have all the info I need, but I guess you should run the build step on a CI/CD tool (TravisCI for example), and push the content of the /dist folder to your production server afterwards. Then, pm2 would only run this production build.
I'm trying to deploy a Next.js project using a Docker image and I was wondering if it's possible to simply use an already generated dist folder (.next) and start the next.js server (npm run start) without having to trigger the build step again in the container.
The container will be hosted in AWS Elastic Beanstalk and I also want to avoid uploading the source code and installing the npm packages there, as I already have a CI pipeline that is generating the production artifacts.
Answering because I was going through issues with this myself and found this question. My research shows the only way to accomplish this is to run a docker environment on beanstalk and not node.js. The primary reason is that there are absolute paths in the .next build artifacts so you have to build on each instance and you have to make sure that BUILD_ID is synced across those instances.
If you CI pipeline can handle creating and pushing the Docker image, then its pretty easy to deploy on Beanstalk without any rebuilding etc. Hope that helps!
I'm unsure how to deploy my web application to heroku where the actual web application is generated within a sub folder. I have the project tree:
app
assets
dist
server
// other stuff ....
now when I want to run my server & frontend, I do gulp. gulp creates a folder named build which contains all needed files for running the web app, so my file tree would become
app
assets
dist
server
build
// other stuff ....
Is there a way to initialize the heroku repository to only the folder build? Since my actual web app lies inside just that folder, it's probably easier for me to only have heroku think the build folder exists.
I currently have heroku setup with only heroku create inside the parent repo
I found a solution to my issue. What I decided to do was include my build folder into my repository (did not add much bloat, only like 50kb). Then, when I wanted to deploy to heroku I did:
git subtree split --prefix build -b deploy
git push heroku deploy:master
git branch -D deploy
this created a branch with only the build folder, pushed that to heroku (use -f if you need to overwrite previous commits), the deleted the deploy branch.
Worked like a charm!
I am searching the net for CD of Git repos to production directly using grunt. Has anyone tried attaching tests and deployment to production on passing tests using Grunt in the server?
My previous general question lead me to Jenkins. Just wondering if the above attachment is possible and any Gruntfile examples
SetupAngularJS or Angular2 Projects for Continuous Integration and Continuous Deployment
I've developed an Angular website that lives in a Node-based project. Gulp is used to build sources into development and production versions of the site. The project includes an ExpressJS server that can serve either the dev or prod versions of the files. Now I want to build and deploy the site in CI fashion.
I have a private NPM registry that I'm able to publish the entire project module to. The easy route would be:
In the build environment, check out the project repository
npm install
pass tests
npm publish
In the production environment..
npm install project
build for production
Run the server over the newly built prod files
But this doesn't seem right. Shouldn't I output the production files as part of the build process, and publish these as a versioned artifact with NPM? Are there acceptable, different ways to publish an NPM module for development and deployment?
Or am I stuck building my sources in the production environment? Doesn't this defeat the purpose of NODE_ENV=production?
It depends where you are hosting your server.
If you want to deploy to heroku, you can follow https://devcenter.heroku.com/articles/getting-started-with-nodejs#introduction and install the gulp build task https://github.com/appstack/heroku-buildpack-nodejs-gulp. Basically, you will push the version you want to deploy to heroku's git server and it will automatically trigger the build process for dev or prod and start the express server. Assuming you are already using git for your project, it is only a matter of adding a new remote.
If you want to deploy to Amazon's elastic beanstalk, it's a little bit more complicated but it all boils down to pushing your application code to the service and this will trigger the build process in the host instance.
If you want to deploy it on your environment you could still use git push and git hook to trigger the deployment. Check out How can I automatically deploy my app after a git push ( GitHub and node.js)? for various implementations.
As for your question "Shouldn't I output the production files as part of the build process, and publish these as a versioned artifact with NPM": you could, but this is not what most people do. As long as your build process is repeatable, there is no reason to package and publish the built version of your app. I am assuming here that your are building an application and not a reusable library in which case it would be a different story.