I thought I could use ${process.env.apiservervariable} for my api calls. I added this into my env.development
NEXT_PUBLIC_REACT_APP_API_SERVER="http://localhost:8000"
which works for npm run dev. But when I build I get errors that I am using incomplete or relative paths. I've switched to using a next.config.js file and putting a var in there like so:
module.exports = {
env: {
apiServer: "http://localhost:8000",
STRIPE_PUBLISHABLE: "pk_test_hash"
},
}
That works, but I have to hardcode it to change it based on the server I want to use. Is there a way to have a variable that gets read from dev when I am using npm run dev and a different one when I run npm run build? I develop locally and then push to github. I pull on the production server and want to be able to build on the server with a different variable for the live server.
You were quite close with your first idea.
In Next.js you can have separate configuration files for development and production environments: create .env.development and .env.production in project root directory. next dev will load the development file and next start the production one. You should include your API_SERVER variable in both files with different values and expose them to the client side by preppending NEXT_PUBLIC_. Thus, you will be able to acces it in your frontend with process.env.NEXT_PUBLIC_API_SERVER.
// .env.development
NEXT_PUBLIC_API_SERVER=http://localhost:3000
// .env.production
NEXT_PUBLIC_API_SERVER=https://google.com
I have been working on implementing some of the updates from Next 9.3. I have been moving from getInitialProps to getServerSideProps and noticed that my exportPathMap became unhappy with these pages becoming dynamic. Everything works fine running next, but when I go to run next build && next export, I run into some issues.
In the docs for static html export it states If your pages don't have getInitialProps you may not need next export at all; next build is already enough thanks to Automatic Static Optimization. I am able to get that to work happily with my new getServerSideProps calls when I run next build && next start. What steps do I need to take in order for that to also work with next export so I can deploy via Netlify. Here's an example of the error I am getting when I attempt to run next export
Error occurred prerendering page "/videos/[videos_title]". Read more: https://err.sh/next.js/prerender-error:
Error: Error for page /videos/[videos_title]: pages with `getServerSideProps` can not be exported. See more info here: https://err.sh/next.js/gssp-export
Applications build with SSR cannot be deployed in Netlify or any other static hosting sites (Except Vercel, which supports NextJS SSR Deployment)
When you go for SSR (using getServerSideProps), it's meaningless to
use the command next export since it will try to create static
content which is totally opposite to the SSR.
One way of deployment is to run it in the Virtual Server (like EC2)
by creating custom server.js file with proper routing configuration.
Another easy & quick method is to use Vercel (Zeit
formerly) for deployment of SSR implemented Applications where
they handle it wisely
Vercel has poor documentation for deployment of SSR Applications. Luckily I've got the below information from the Support Team and requested them to update the documentation to elaborate more about the SSR Deployment in Vercel.
When deploying in Vercel,
Give Build Command as next build or npm run build
Leave the Output Directory as Empty
NOTE: Application with custom server.js will not work properly in Vercel, in that case, go for Virtual Server (Like EC2)
As you should see in the images below, the css on my local host site is spaced much better at the top than it is on heroku.
Has anyone had this type of problem before. You can see it best on this page http://pltcpal.herokuapp.com/forums/
I'm using Twitter bootstrap, which recommends adding
`padding-top: 40px;`
to body if using the top nav bar. Somehow it's not working...
The problem is related to the handling of the asset pipeline on Heroku. There are several ways on how this can be handled, see http://devcenter.heroku.com/articles/rails31_heroku_cedar
I fixed the issue in my application by pre-compiling the assets locally on my machine and then pushing them to Heroku.
Pre-compile the assets:
RAILS_ENV=production bundle exec rake assets:precompile
Add/commit the changes to git repository:
git add public/assets
git commit -m "vendor compiled assets"
To be safe I tested the whole thing on a local branch on my machine first which I pushed to Heroku using the following command (Heroku normally ignores all branches except the master branch, thus the trick):
git push -f heroku heroku-assetpipeline:master
FWIW, I had this same issue and checked everything I could think of, as well as those above. It turned out I must have zoomed out in my browser while on localhost, and I had the standard zoom on my production url.
It was as simple as resetting the zoom in my browser on both pages. Hope this helps someone else with the same problem.
I have the very same issue.
When I compare the development and production code, it occurs that on the development machine the stylesheets and javascript files from bootstrap all get loaded whereby on the production site (Heroku), there is only one application-XYZ.css and one application-XYZ.js.
I am not sure if this could be an issue with the asset pipeline.
Could probably someone elaborate on what needs to be done to (pre-)compile the asset pipeline such that deployment on Heroku succeeds.
Is it possible that you pre-compiled your assets locally at some point? To force heroku to compile your assets during slug compilation you can rename your public/assets/manifest.yml to public/assets/manifest.yml.bak, commit your source, and push to heroku.
Heroku assumes you compiled your assets locally when it sees the manifest.yml file.
I had this same problem and followed the instructions of a couple of different pages including Heroku's own documentation. I'm posting here to help the next guy because possibly due to changes in Rails 4, Heroku, or Github but the above directions did not work at all for me. However I did get it to work and here's how.
Yes you probably should precompile your assets using RAILS_ENV=production bundle exec rake assets:precompile but after that go into you 'public/assets' folder and copy "all" '.css','css.gz', '.json', '.yml', '.js' files that start either with 'application' or 'manifest'. Move them to a folder outside of the application's directories. Do this just encase anything goes wrong. Verify all of those files are deleted from the apps 'public/assets/' folder. Next restart your local rails server and verify your app is still behaving as you intend it to. Then go to your Github account and go into the 'public/assets/' directory of your repository and delete all the same files that you just did locally. Then add/commit locally, then push to git, then to heroku, and walla you're done it should be working.
The rationale behind it, what I assume, is because when you push to Heroku it checks for compiled assets in your repository and because of this, even though I had precompiled locally, it was still pulling some asset configurations from previous commits. By removing these files, Heroku must compile them during the push. One thing I didn't try which may work is just switching to another branch and deleting those files and deploying that branch to Heroku, so you may want to try that first, but this is what worked for me.
One other note, renaming the files to .bak or .old Heroku still considered them as their regulars and displayed them as it was the original ones that were not displaying properly.
I'm using a blank VS2010 solution to manage a static website I maintain. I was going to use the ASP.NET website project, but that added a bunch of stuff the webserver wouldn't do. If I should still use that project, please let me know!
I have the code under source control and try to have the DEV region in source mirror the DEV webserver. I want to migrate my changes to the dev server for others to view, but I'm not sure of the best method to do this. If I use the Publish Website command in VS, it will delete the files on the server and copy all the files. The problem with this is that it takes waaayyy too long. Especially when I am on the VPN. I could manually copy the files, but that's a sloppy way to do it. And the server doesn't have FTP so that's not an option either. Is there some blatant method I am missing?
I thought about setting up a workspace with the server as the working folder. Then, whenever I wanted to migrate a change, I'd just do a "get latest" in that workspace and it would bring down any files that have changed. Does this sound like an okay method or is there a preferred method for this?
Have you tried the copy/website functionality
First of all, I recommend against using web site "projects" for anything. Use a Web Application Project instead.
Secondly, when you use MSDEPLOY from the Publish command, it synchronizes the target web site with the source - it will only deploy changed content.
Set up a continuous integration server (ex. CruiseControl.NET).
Create a new build project for each website you wish to deploy, initially configured for manual invocation.
Configure the build project to do a get latest and deploy.
Here are some possible implementations:
http://callicode.com/Homeltpagegt/tabid/38/EntryId/27/How-to-only-publish-the-runtime-files-of-an-asp-net-application-using-CruiseControl-net.aspx
http://confluence.public.thoughtworks.org/display/CCNET/Build+Publisher
I am looking for different techniques/tools you use to deploy an ASP.NET web application project (NOT ASP.NET web site) to production?
I am particularly interested of the workflow happening between the time your Continuous Integration Build server drops the binaries at some location and the time the first user request hits these binaries.
Are you using some specific tools or just XCOPY? How is the application packaged (ZIP, MSI, ...)?
When an application is deployed for the first time how do you setup the App Pool and Virtual Directory (do you create them manually or with some tool)?
When a static resource changes (CSS, JS or image file) do you redeploy the whole application or only the modified resource? How about when an assembly/ASPX page changes?
Do you keep track of all deployed versions for a given application and in case something goes wrong do you have procedures of restoring the application to a previous known working state?
Feel free to complete the previous list.
And here's what we use to deploy our ASP.NET applications:
We add a Web Deployment Project to the solution and set it up to build the ASP.NET web application
We add a Setup Project (NOT Web Setup Project) to the solution and set it to take the output of the Web Deployment Project
We add a custom install action and in the OnInstall event we run a custom build .NET assembly that creates an App Pool and a Virtual Directory in IIS using System.DirectoryServices.DirectoryEntry (This task is performed only the first time an application is deployed). We support multiple Web Sites in IIS, Authentication for Virtual Directories and setting identities for App Pools.
We add a custom task in TFS to build the Setup Project (TFS does not support Setup Projects so we had to use devenv.exe to build the MSI)
The MSI is installed on the live server (if there's a previous version of the MSI it is first uninstalled)
We have all of our code deployed in MSIs using Setup Factory. If something has to change we redeploy the entire solution. This sounds like overkill for a css file, but it absolutely keeps all environments in sync, and we know exactly what is in production (we deploy to all test and uat environments the same way).
We do rolling deployment to the live servers, so we don't use installer projects; we have something more like CI:
"live" build-server builds from the approved source (not the "HEAD" of the repo)
(after it has taken a backup ;-p)
robocopy publishes to a staging server ("live", but not in the F5 cluster)
final validation done on the staging server, often with "hosts" hacks to emulate the entire thing as closely as possible
robocopy /L is used automatically to distribute a list of the changes in the next "push", to alert of any goofs
as part of a scheduled process, the cluster is cycled, deploying to the nodes in the cluster via robocopy (while they are out of the cluster)
robocopy automatically ensures that only changes are deployed.
Re the App Pool etc; I would love this to be automated (see this question), but at the moment it is manual. I really want to change that, though.
(it probably helps that we have our own data-centre and server-farm "on-site", so we don't have to cross many hurdles)
Website
Deployer:
http://www.codeproject.com/KB/install/deployer.aspx
I publish website to a local folder, zip it, then upload it over FTP. Deployer on server then extracts zip, replaces config values (in Web.Config and other files), and that's it.
Of course for first run you need to connect to the server and setup IIS WebSite, database, but after that publishing updates is piece of cake.
Database
For keeping databases in sync I use http://www.red-gate.com/products/sql-development/sql-compare/
If server is behind bunch of routers and you can't directly connect (which is requirement of SQL Compare), use https://secure.logmein.com/products/hamachi2/ to create VPN.
I deploy mostly ASP.NET apps to Linux servers and redeploy everything for even the smallest change. Here is my standard workflow:
I use a source code repository (like Subversion)
On the server, I have a bash script that does the following:
Checks out the latest code
Does a build (creates the DLLs)
Filters the files down to the essentials (removes code files for example)
Backs up the database
Deploys the files to the web server in a directory named with the current date
Updates the database if a new schema is included in the deployment
Makes the new installation the default one so it will be served with the next hit
Checkout is done with the command-line version of Subversion and building is done with xbuild (msbuild work-alike from the Mono project). Most of the magic is done in ReleaseIt.
On my dev server I essentially have continuous integration but on the production side I actually SSH into the server and initiate the deployment manually by running the script. My script is cleverly called 'deploy' so that is what I type at the bash prompt. I am very creative. Not.
In production, I have to type 'deploy' twice: once to check-out, build, and deploy to a dated directory and once to make that directory the default instance. Since the directories are dated, I can revert to any previous deployment simply by typing 'deploy' from within the relevant directory.
Initial deployment takes a couple of minutes and reversion to a prior version takes a few seconds.
It has been a nice solution for me and relies only on the three command-line utilities (svn, xbuild, and releaseit), the DB client, SSH, and Bash.
I really need to update the copy of ReleaseIt on CodePlex sometime:
http://releaseit.codeplex.com/
Simple XCopy for ASP.NET. Zip it up, sftp to the server, extract into the right location. For the first deployment, manual set up of IIS
Answering your questions:
XCopy
Manually
For static resources, we only deploy the changed resource.
For DLL's we deploy the changed DLL and ASPX pages.
Yes, and yes.
Keeping it nice and simple has saved us alot of headaches so far.
Are you using some specific tools or just XCOPY? How is the application packaged (ZIP, MSI, ...)?
As a developer for BuildMaster, this is naturally what I use. All applications are built and packaged within the tool as artifacts, which are stored internally as ZIP files.
When an application is deployed for the first time how do you setup the App Pool and Virtual Directory (do you create them manually or with some tool)?
Manually - we create a change control within the tool that reminds us the exact steps to perform in future environments as the application moves through its testing environments. This could also be automated with a simple PowerShell script, but we do not add new applications very often so it's just as easy to spend the 1 minute it takes to create the site manually.
When a static resource changes (CSS, JS or image file) do you redeploy the whole application or only the modified resource? How about when an assembly/ASPX page changes?
By default, the process of deploying artifacts is set-up such that only files that are modified are transferred to the target server - this includes everything from CSS files, JavaScript files, ASPX pages, and linked assemblies.
Do you keep track of all deployed versions for a given application and in case something goes wrong do you have procedures of restoring the application to a previous known working state?
Yes, BuildMaster handles all of this for us. Restoring is mostly as simple as re-executing an old build promotion, but sometimes database changes need to be manually restored, and data loss can occur. The basic rollback process is detailed here: http://inedo.com/support/tutorials/performing-a-deployment-rollback-with-buildmaster
web setup/install projects - so you can easily uninstall it if something goes wrong
Unfold is a capistrano-like deployment solution I wrote for .net applications. It is what we use on all of our projects and it's a very flexible solution. It solves most of the typical problems for .net applications as explained in this blog post by Rob Conery.
it comes with a good "default" behavior, in the sense that it does a lot of standard stuff for you: getting the code from source control, building, creating the application pool, setting up IIS, etc
releases based on what's in source control
it has task hooks, so the default behaviour can be easily extended or altered
it has rollback
it's all powershell, so there aren't any external dependencies
it uses powershell remoting to access remote machines
Here's an introduction and some other blog posts.
So to answer the questions above:
How is the application packaged (ZIP, MSI, ...)?
Git (or another scm) is the default way to get the application on the target machine. Alternatively you can perform a local build and copy the result over the Powereshell remoting connection
When an application is deployed for the first time how do you setup the App Pool and Virtual Directory (do you create them manually or with some tool)?
Unfold configures the application pool and website application using Powershell's WebAdministration Module. It allows us (and you) to modify any aspect of the application pool or website
When a static resource changes (CSS, JS or image file) do you redeploy the whole application or only the modified resource? How about when an assembly/ASPX page changes?
Yes unfold does this, any deploy is installed next to the others. That way we can easily rollback
when somehting goes wrong. It also allows us to easily trace back a deployed version to
a source control revision.
Do you keep track of all deployed versions for a given application?
Yes, unfold keeps old versions around. Not all versions, but a number of versions. It makes rolling back almost trivial.
We've been improving our release process for the past year and now we've got it down pat. I'm using Jenkins to manage all of our automated builds and releases, but I'm sure you could use TeamCity or CruiseControl.
So upon checkin, our "normal" build does the following:
Jenkins does a SVN update to fetch the latest version of the code
A NuGet package restore is done running against our own local NuGet repository
The application is compiled using MsBuild. Setting this up is an adventure, because you need to install the correct MsBuild and then the ASP.NET and MVC dll's on your build box. (As a side note, when I had <MvcBuildViews>true</MvcBuildViews> entered in my .csproj files to compile the views, msbuild was randomly crashing, so I had to disable it)
Once the code is compiled the unit tests are run (I'm using nunit for this, but you can use anything you want)
If all the unit tests pass, I stop the IIS app pool, deploy the app locally (just a few basic XCOPY commands to copy over the necessary files) and then restart IIS (I've had problems with IIS locking files, and this solved it)
I have separate web.config files for each environment; dev, uat, prod. (I tried using the web transformation stuff with little success). So the right web.config file is also copied across
I then use PhantomJS to execute a bunch of UI tests. It also takes a bunch of screenshots at different resolutions (mobile, desktop) and stamps each screenshot with some information (page title, resolution). Jenkins has great support for handling these screenshots and they are saved as part of the build
Once the integration UI tests pass the build is successful
If someone clicks "Deploy to UAT":
If the last build was successful, Jenkins does another SVN update
The application is compiled using a RELEASE configuration
A "www" directory is created and the application is copied into it
I then use winscp to synchronise the filesystem between the build box and UAT
I send a HTTP request to the UAT server and make sure I get back a 200
This revision is tagged in SVN as UAT-datetime
If we've got this far, build is successful!
When we click "Deploy to Prod":
The user selects a UAT Tag that was previously created
The tag is "switched" to
Code is compiled and synced with Prod server
Http request to Prod server
This revision is tagged in SVN as Prod-datetime
The release is zipped and stored
All up a full build to production takes about 30 secs which I'm very, very happy with.
Upsides to this solution:
It's fast
Unit tests should catch logic errors
When a UI bug gets into production, the screenshots will hopefully show what revision # caused the it
UAT and Prod are kept in sync
Jenkins shows you a great release history to UAT and Prod with all of the commit messages
UAT and Prod releases are all tagged automatically
You can see when releases happen and who did them
The main downsides to this solution are:
Whenever you do a release to Prod you need to do a release to UAT. This was a conscious decision we made because we wanted to always ensure that UAT is always up to date with Prod. Still, it's a pain.
There's quite a few configuration files floating around. I've attempted to have it all in Jenkins, but there's a few support batch files needed as part of the process. (These are also checked in).
DB upgrade and downgrade scripts are part of the app and run at app startup. It works (mostly), but it's a pain.
I'd love to hear any other possible improvements!
Back in 2009, where this answer hails from, we used CruiseControl.net for our Continuous Integration builds, which also outputted Release Media.
From there we used Smart Sync software to compare against a production server that was out of the load balanced pool, and moved the changes up.
Finally, after validating the release, we ran a DOS script that primarily used RoboCopy to sync the code over to the live servers, stopping/starting IIS as it went.
At the last company I worked for we used to deploy using an rSync batch file to upload only the changes since the last upload. The beauty of rSync is that you can add exclude lists to exclude specific files or filename patterns. So excluding all of our .cs files, solution and project files is really easy, for instance.
We were using TortoiseSVN for version control, and so it was nice to be able to write in several SVN commands to accomplish the following:
First off, check the user has the latest revision. If not, either prompt them to update or run the update right there and then.
Download a text file from the server called "synclog.txt" that details who the SVN user is, what revision number they are uploading and the date and time of the upload. Append a new line for the current upload and then send it back to the server along with the changed files. This makes it extremely easy to find out what version of the site to roll back to on the off chance that an upload causes problems.
In addition to this there is a second batch file that just checks for file differences on the live server. This can highlight the common problem where someone would upload but not commit their changes to SVN. Combined with the sync log mentioned above we could find out who the likely culprit was and ask them to commit their work.
And lastly, rSync allows you to take a backup of the files that were replaced during the upload. We had it move them into a backup folder So if you suddenly realised that some of the files should not have been overwritten, you can find the last backup up version of every file in that folder.
While the solution felt a little clunky at the time I have since come to appreciate it a whole lot more when working in environments where the upload method is a lot less elegant or easy (remote desktop, copy and paste the entire site, for instance).
I'd recommend NOT just overwriting existing application files but instead create a directory per version and repointing the IIS application to the new path.
This has several benefits:
Quick to revert if needed
No need to stop IIS or the app pool to avoid locking issues
No risk of old files causing problems
More or less zero downtime (usually just a pause at the new appdomain initialises)
The only issue we've had is resources being cached if you don't restart the app pool and rely on the automatic appdomain switch.