Is there a way to create a deployment of my Nextjs app to production but without promoting it immediately to prod? Similar to a preview URL, but without public traffic being routed to that URL.
My use case is that I want to deploy a "pre-prod" app, run E2E tests there, and if they are successful, promote the app to production.
Is this flow possible?
I've used vercel --prod, but that just deploys the current version to production.
I want to create a production build that allows me to then use the alias command to point the traffic to a specific version.
Thanks in advance!
In this case, my opinion, you need to create an "intermediate" solution.
In vercel, you have "dev" "preview" and "production" environments (go to Settings-environment variables). You set some settings to preview env, it's ok for you, you can after "promote to production" your preview version.
Also, you can set up a special branch in git to directly deployment on preview
Related
I just installed a ghost production environment on ubuntu 20.04 VPS with 1GB ram. I have also set up a dev environment locally on my mac where ill try out all my experiments.
My prod ghost installation is currently configured to the subdomain. ie.
blog.mydomain.com
I want to use ghost for managing most of my website, except for a few pages like the home page and my projects page, where I'd like to set up custom static sites with next.js or gatsby.
Is there any way to configure ghost to a subfolder within my root - and run
mycompany.com/blog
and use ssgs for the home and projects page.
If this isn't possible, Is there some other way to achieve this.
Thank you soo much for the help!!😀
Have you take a look at path prefixing? Adding the following in your gatsby-config.js should change your (sub)domain to /blog:
module.exports = {
pathPrefix: `/blog`,
}
Be aware that adding a pathPrefix you will force you to tweak your build and serve commands by adding the --prefix-paths flag
I would like to have a way to toggle between production and dev endpoints within from the phone settings. I am worried that this will mess up the cash and might display incorrect data. what's the best way to do it, please?
I was wondering the same thing!
In your code, you can use the __DEV__ global flag to differentiate between Dev and Production "mode".
Expo's Production switch is not a reliable way to handle environment switches (production and dev endpoints in your case). Why? 2 main reasons:
Production mode always minifies your code and better represents the performance your app will have on end-user's devices.
Development mode includes useful warnings and gives you access to debugging tools.
What if you want to have the flexibility to run the app against the Production endpoints you have, but still being able to access the debugging tools? You can't.
Here's my approach: I handle environment switches with .env files.
With Expo, I got my .env to work with the following:
Added babel-plugin-inline-dotenv to devDependencies:
npm install --save-dev babel-plugin-inline-dotenv
Added inline-dotenv to .babelrc:
{
"plugins": ["inline-dotenv"]
}
Added a .env file:
ENDPOINT="https://development"
Kudos for the .env set-up instructions goes to jdrydn.
Finally, use the environment variable in your code:
<Text>{process.env.ENDPOINT}</Text>
Plus, I have one more file .env-production (technically, I have also .env-staging in case you're wondering):
ENDPOINT="https://production"
The real caveat is when you want to run your app against the Production environment. You need to:
Copy .env-production content to the .env file.
Restart Expo's Metro Bundler and clear its cache (must be always restarted between .env changes). Do that either by running expo r -c or by pressing shift-r in your terminal to restart and clear cache while the Metro Bundler is running.
That's the most optimal approach I've been able to find.
PS: If you want to toggle between Dev and Production endpoints within you app - I'd simply use a js file with exported variables for each environment.
I am working on developing a client-side application built on EmberJS.
Now, while I test the code in the browser ultimately, I have the following locally for development;
NodeJS & NPM
I have defined bower.json & package.json
I use ember-cli & do ember build & ember server to start the local server
I hit the URL http://localhost:4200 in the browser to access the app
Now my question is I wanted to understand, what exactly is happening here ?
Meaning what exactly happens before code runs in the browser.
I understand when the build happens, it actually pushes code into the 'dist' directory.
Is there any role in NodeJS in all of this (meaning any JS run on server-side in the background) OR we just utilize npm/bower for this case ?
So I just wanted to connect all the dots regarding running in the browser.
browsers don't support the features of modern javascript, so when you end up deploying your ember site, you only need to deploy static files (from the dist directory), and you actually don't need a server at all.
This is how https://emberclear.io works (no server, just a CDN).
The NodeJS things are purely for pre-deployment needs (development, transpiling, testing, etc).
Hope this helps.
I'm learning to use webpack-encore and noticed it is installed only as a dev dependency. Does that mean I should compile my js and css files on development and push them to the repository, and then to production?
That seems to me what the docs are implying, but wouldn't that mean a merge-conflict hell? Compiled files would be impossible to merge.
Also wouldn't that be contrary to version control philosophy? As far as I know, you don't publish binaries in compiled languages (i.e. C/C++), you push the code and expect the server to compile them. I know this isn't the same type of "compilation" in javascript, but what is the expected behavior of the production server in this case? To receive the files ready to serve them, or to compile them at the time of release?
Thanks in advance
Does that mean I should compile my js and css files on development and push them to the repository, and then to production?
Not exactly - it depends on how you deploy.
When you deploy, you need to run ./node_modules/.bin/encore production to build your assets. Once you've done this, only your built assets (e.g. web/build) need to be transferred to production.
You could run this command locally (or on some "build" server) and the transfer all the files to production. Or, you could use a git pull on production, and then run this command on production (the downside being that you would need Node.js installed on production).
You shouldn't / don't need to commit your built files to your repository. But... if it simplifies your deploy (i.e. you want to do a git pull and be done), there's no real problem with that.
I just added a PR to answer these in the FAQ (http://symfony.com/doc/current/frontend/encore/faq.html) - here's the PR until it's deployed: https://github.com/symfony/symfony-docs/pull/8109
Cheers!
Solution 1:
Run yarn run encore production locally
Check out which files have been created / modified
Add them to VCS
Commit
Push / deploy
Solution 2:
Push / deploy
Run yarn run encore production remotely during deployment
To my eyes the 2nd solution is way better, because you don't need an extra human-checking before deployment, everything is automated.
But this has a strong drawback: building assets can be a slow process, and when I deploy, my production is down during 5 to 20 seconds until assets are built.
Here's the HTTP 500 error:
An exception has been thrown during the rendering of a template ("Asset manifest file "[...]/web/build/manifest.json" does not exist.").
It looks like the manifest.json file is deleted at the beginning of the process, and created from scratch later on.
Something that should be improved?
I have been looking over this tutorial: http://ox86.tumblr.com/post/45184656062/running-your-meteor-js-application-on-your-own-server but having a hard time understanding how it works.
All of my code is in git (on bitbucket.org) so, I can skip the bundling command, but do I need to install Node.js separate from installing Meteor or does installing Meteor take care of that for me?
Meteor requires NodeJS (it runs on it), so you need to install NodeJS first.
Meteor uses MongoDB so you need to install it as well.
Next up, install Meteor of course. It's on their website.
You'd need Meteorite for packages, if any.
Then bundle and deploy your application.
With all that hassle in the tutorial, there are other ways to do installation, and is much more easier.
Deploy to meteor.com. They allow you to host your apps under a subdomain of meteor.com. Then, purchase your own domain name, and have it point to your subdomain:
You can also deploy to your own domain. Just set up the hostname you want to use as a CNAME to origin.meteor.com, then deploy to that name.
Platform-As-A-Service (PAAS). Heroku would be a good example. They give you a platform to run your apps, not necessarily just a web server. It's similar to how meteor.com runs. Likewise, you can also purchase a domain name and point to it.
Virtual Private Server. It's a computer in the cloud. They typically run Linux. You get SSH access to it, and run stuff like you would on the terminal of your PC. This would require a bit more technical stuff. Just added it here for reference.