I'm building a Node.js application and I'm using Heroku as my host. I want to be able to maybe have a development subdomain for my app where I can test changes before I push it into production. It'd be great if I could do something like git push heroku dev, and access my prerelease code at dev.myapp.heroku.com or something similar. Is something like that possible without having to set up an entirely separate app? If not, how would I configure the toolbelt to push to 2 different Heroku apps from different branches of the same repository?
I usually just create another app for staging
then add the remote for the new app like
git remote add staging https://git.heroku.com/staging.git
then you can push your development branch to the staging master branch like
git push staging development:master
i think it's actually kind of nice to have 2 different apps, so you can try out new settings or addons without messing with your production instance.
you can always add a dev.yourapp.com as a domain for this app, then point your dns to it. here is a link to a detailed way to do that
https://devcenter.heroku.com/articles/custom-domains#add-a-custom-domain-with-a-subdomain
Very easy. Use Heroku Pipelines.
You put your Dev app and your Production app in a pipeline (you might want to also add a Staging app in the pipeline - up to you).
The you push to your dev app from your development environment.
Test everything in the dev app, and when you're satisfied, you simply "Promote" the compiled slug to the next phase in the pipeline.
Related
I have a DigitalOcean VPS with ubuntu and a few laravel projects, for my projects initial setup I do a git clone to create a folder with my application files from my online repository.
I do all development work in my local machine, where I have two branches (master and develop), what I do is merge develop into my local master, then I push from master into my local repository.
Nw back into my production server, when I want to add all the changes added into production I do a git pull from origin, so far this has resulted into git telling me to stash my changes, why is this?
What would be the best approach to pull changes into production server? take in mind that my production server has no working directory perse, all I do in my VPS is either clone or push upgrades into production.
You can take a look at the CI/CD (continuous integration / continuous delivery) systems. GitLab for example offer free-to-use plan for small teams.
You can create a pipeline with a manual deploy step (you have to press a button after the code is merged to the master branch) and use whatever tool you like to deploy your code (scp, rsync, ftp, sftp etc.).
And the biggest benefit is that you can have multiple intermediate steps (even for the working branches) where you can run unit tests which would prevent you to upload failing builds (whenever you merge non-working code)
For the first problem, do a git status on production to see which files that git sees as changed or added and consider adding them to your .gitignore file (which itself should be a part of your repo). Laravel generally has good defaults for these, but you might have added things or deviated from them in the process of upgrading Laravel.
For the deployment, the best practice is to have something that is consistent, reproducible, loggable, and revertable. For this, I would recommend choosing a deployment utility. These usually do pretty much the same thing:
You define deployment parameters in code, which you can commit as a part of your repo (not passwords, of course, but things like the server name, deploy path, and deploy tasks).
You initiate a deploy directly from your local computer.
The script/utility SSH's into your target server and pulls the latest code from the remote git repo (authorized via SSH key forwarded into the server) into a 'release' folder.
The script does any additional tasks you define (composer install, npm run prod, systemctl restart php-fpm, soft-linking shared files like .env, and etc.)
The script soft-links the document root to your new 'release' folder, which results in an essentially zero-downtime deployment. If any of the previous steps fail, or you find a bug in the latest release, you just soft-link to the previous release folder and your site still works.
Here are some solutions you can check out that all do this sort of thing:
Laravel Envoyer: A 1st-party (paid) service that allows you to deploy via a web-based GUI.
Laravel Envoy: A 1st-party (free) package that allows you to connect to your prod server and script deployment tasks. It's very bare-bones in that you have to write all of the commands yourself, but some may prefer that.
Capistrano: This is (free) a tried-and-tested popular ruby-based deployment utility.
Deployer: The (free) PHP equivalent of Capistrano. Easier to use, has a lot of built-in tasks (including a Laravel one), and doesn't require ruby.
Using these utilities is not necessarily exclusive of doing CI/CD if you want to go that route. You can use these tools to define the CD step in your pipeline while still doing other steps beforehand.
I'm getting lost in the heroku documentation but I've basically finished the following steps and now I want to view the webpage showing the app (not on my local machine but on the web).
1) I've used package.json to specify the build of my node.js project
2) I've used a pipeline to connect my github project black-tomcat-dev/heroku-node-test to my main heroku app so once I update my own github repo it updates the main project.
3) Ive created express.js routing command to get to make a cool page that creates smileys.
**EDIT How does the pipeline work How can I push code from my black-tomcat-dev repo to the test environment in my main heroku app
This is a heroku, node.js and github question.
Pipelines in Heroku is basically a collection of individual Heroku apps. All the apps literally shares the same code between each other. It is similar to Continuous Delivery. Where it flows like
Review --> Development ---> Staging ----> Production
As you have connected GitHub with Heroku already, for every pull request, Heroku will automatically create an app (here, review app).
When you merge the pull request to master branch in GitHub, Heroku will automatically deploy the branch to Staging.
From the staging, you need to promote your app to production. This can be done either from Heroku environment or through command line - heroku pipelines:promote
Since you have only one app, this doesn't require pipeline. So, once you deploy to Heroku, you can directly open the app using command line:
heroku open -a <your_app_name_here>
I have a node.js application on my Github. Right now I am using Heroku for hosting it but I want to give DigitialOcean a try (the $5/month is more affordable).
I am used to using Heroku, where I just go create an app > connect it to my github account > deploy from the master branch > boom app deployed.
When I signed up for DO and started exploring it seemed way too much and too many steps to get my app deployed. I researched around to find a simpler way (similar to one I follow in Heroku) but all the blogs and YouTube videos go through the same tedious process.
I know I am being lazy but I just need a few clicks app deployment. Does anyone know a better (smarter) way I can deploy my app on DO from Github?
It will not be as easy with Heroku. It is always tempting to use cheaper services like Digital Ocean or Vultr and pay only fraction of the price (especially using coupon links that can make it free for months - Digital Ocean, Vultr) but having your own VPS means that you need to manage it yourself. Simplifying that process is what you pay for when you're using Heroku. But it doesn't have to be that bad.
Here is a good tutorial on how to do it:
https://www.distelli.com/docs/tutorials/build-and-deploy-nodejs-to-digitalocean/
And see this list of tutorials - search for those with "deploy" in the title:
https://www.digitalocean.com/community/tags/node-js?type=tutorials
Basically you have few options that I would consider here:
A semi-manual deploy with git - You can install a git server on your VPS and push to it whenever you want to deploy a new version
Automatic deploy with git - You can add a deployment process to you CI scripts that will do what you do manually in (1) but after all tests pass
You can trigger a pull from git on the server with ssh or a custom API
You can do (3) in your CI scripts
You can add a custom webhook in GitHub to notify your server about new version and your server may then pull the code and restart
You can add a custom webhook in CI and do the same as in (5)
I'am looking for a simple and straightforward way to deploy a node application from the repo service (bitbucket or gitlab) to a separate server/vps.
I want to proceed so that a push to the repo would trigger a deploy on the server (one for a staging environment and one for production) When initially looking into this I get uncertain on what would be best, easiest, most efficient, best practice and so on. What tools should I pick, a gitlab runner or is it possible with pm2, some webhook or some other node npm service that could be installed on the vps for this? Any suggestions or links to further info would be appreciated.
I would suggest you trying CI/CD tool like Jenkins, but I needs to be run separately.
You can set cron at Jenkins to check repo changes, it's the easiest way. Better way would be using webhooks like Bitbucket Webhook Jenkins addon. Here is setup guide for Gitlab.
Jenkins installation guide
Overview
I have 2 servers, One server is local and other is hosted off site.
1 - Production
1 - Development
The Production is hosted and has an outside IP to be accessed from anyone on the web.
The Development can only be accessed internally ( No outside IP ).
They both use the same URL www.blah.com and our developers manage to switch between the two sites by editing their windows hosts file to point to the correct server.
The Problem
How would I update the development server though Github on a push with a hook becuase there is no internet URL? I suppose I could create a CRON but I would love to use a hook somehow to only update when a push happens. Production has a URL so I can use Github to do a post hook to update.
If I understand correctly:
When PROD is pushed to, you want to update DEV
PROD cannot access DEV
In this case you PROD cannot update DEV directly. If there is another site MIDDLE that PROD can access, and MIDDLE can access DEV, then you could setup a chain of triggers from PROD -> MIDDLE -> DEV. Otherwise the only way is a cron job on DEV, polling periodically.
If PROD could access DEV directly then you could setup a web hook, which could trigger a script on DEV, which could perform a pull from PROD. This is a common practice.