How to deploy Rails to a Staging Environment

[Music] hey guys this episode we're talking about deploying rails to a staging environment and how to set all of that up now rails comes with three environments out of the box we have test where we run our test suite and check that all of our code works that runs locally or on a ci server somewhere we have the development environment which we use locally and it's optimized for editing and changing things all the time and then we have the production environment which is optimized for loading things and caching them and making it run as fast as possible production is where we deploy the code to a remote server somewhere it has a database and a domain pointing to it and our users are using that as the real application so when we talk about setting up a staging environment we want something very close to production but we want it in a test environment so we can go test new features and make sure sure that they work with real data and with other users and then we can go to production and deploy that and know that we've tested it locally and in staging and that it should be safe for production so when you're building complex applications a staging environment it's great to be able to test things with other people and have a server that's on the internet that you can use to test with those other developers or teammates that you're working with so let's go and set up a staging environment in a rails app now when rails boots the config application.rb file is where things start this is where configuration is set up for the entire set of environments so test production development everything you should use these settings so for example a time zone you want that to be the same whether or not you're in test or development or production you want them all to use the same time zone but there are a lot of things that are specific to development or test or production for example in development we don't want to send out real emails so we'll set up something like letter opener so we can send an email and it will just be stored as a file on disk and we can see it generated the correct email but in production we want to actually send the email out so we need something like postmark or send grid to actually send the emails also in development we don't do caching and things generally because we need to edit files and we don't want an old stale version of that on accident so we generally turn off caching for development and in production we enable caching of classes we eager load everything and so on and that is where rails can optimize for performance so we're staging environment needs to be closest to production as possible but there are things that we don't want to do maybe we don't want to send emails out to real users we could use an interceptor for that or we could just turn off email sending in staging and the way that we can set this up is we can go and copy the production environment file and we'll create a new file called staging.rb and we want to keep this as similar to production as possible so for example we'll leave all of these settings the same but we might go in here and change the email settings and change it so that it doesn't actually send out real emails or we'll add an interceptor so any emails that are sent out gets sent to us as employees of the company but not actually real users in case there was a real email in the staging database speaking of databases we want to go into our config database dot yaml file and we want to add a staging section in here and again in general you're going to want to copy the production environment every time and then make adjustments to it and rename it to staging so we'll call this one to-do list staging and we can leave the environment the same but generally when we deploy to heroku or render or hatchbox they're all going to be setting a database url environment variable and it's going to ignore this information set here but it's good to have it just in case so in general it's going to use the database url environment variable instead of this now you're going to want to go through all of the rest of your configuration files as well so for example with storage.yaml we may have one here for amazon storage we're going to want to copy that for staging and put it in a different bucket for staging so you might have a bucket called you know my app bucket but you will want for staging to have one that's like my app staging and upload those staging files there instead so i'm not actually using that in this example because i don't have an app that uses active storage but it's something important to go through this file your if you have secrets you want staging in here as well if you have rails credentials you want to add the rails credentials environment there so for example we'll run rails credentials edit environment equals staging and this will open up a staging credentials file and we can go and put for example here our aws secrets if we uncomment those what we'll see here is that we have now config credential staging dot key and config credentials staging.yaml.encrypted and so we'll take this staging key and set that as the rails master key in our production or our staging environment on heroku so you'll want to go through and change all of those configuration settings so that there are separate databases separate upload locations separate sidekick configurations for staging because generally staging will use the same stuff as production a pro postgres database on each but they'll be separate and staging will be smaller production will have real production data maybe hundreds of gigs and staging will maybe have one gig of data and it doesn't need to be as expensive as production is so this is where we can go and fine-tune everything and set up those two different environments once you've gone through all these files there's not very many that you have to touch but there will be several once you've gone through those you can commit them to git and you can say git add and you can add your config staging or environments staging dot rb you'll want to add your yaml encrypted file so get add config credentials staging yaml encrypted and so on for all of your other changes now the last thing i want to mention is that you can have gems for specific environments so let's take a look at our gem file this is pretty typical we have gems that are available in every environment and you can see those here like rails we always want rails no matter what environment we are in but in development and test we may want by bug so by bug is in a group called development and a group called test which match the rails environment so the gem file is also going to be affected by that so you want to make sure that if you have a gem in here and it's got group production on it you also want to make sure that it is in the staging group as well so that's an important thing to know we don't have any that are specific to production or staging and in general the gems that you will want in production you want in every other environment as well it's not super common but it can happen so i wanted to mention that before we move on then once you're done you can say git commit dash m add staging environment and you can commit this and then push that up to your git host and we can then go deploy our application so here on heroku i've deployed the app into production which is the default for heroku it's going to always deploy as the production environment we have added a database and deployed our code and what heroku has done is set some config variables automatically for us it set the rack environment and the rails environment to production so to run staging we need to set rack end and rails m to staging and then rails will know and rack will know as well that we need to load that config staging.rb file and that is really all there is to it so we can go into heroku and create a new application and we can go into settings and we can say let's add the rack and staging we'll add that we'll add rails and as staging there we go and we need to run the heroku command to add the git remote and we're going to call ours heroku staging because i already have the heroku get remote set up for production and we're going to name our app here and that's going to be staging example app and there we go so now we can get push heroku staging master and that's going to push our code up to the heroku staging environment and deploy it so this will have the new rack and rails m's already set as it goes through and installs our code and all our application stuff and we'll be able to see in here that they will fill in some of those other environment variables like we see in this app for our rails log to standard out and things like that because they'll detect that it is a rails application but we'll go through and wait for this deployment to finish in order to see all of those changes and now that our deployment is complete we can refresh our heroku application and under the config vars now we'll see rails log to standard out rail serve static files and so on have been generated for us automatically because it detected that there was a rails app so this is good to go now and on our overview we'll need to make sure we have a heroku postgres database added you can go ahead and add that yourself if you need it you might also need redis but you can add your databases and things now and then we can go into our terminal and run heroku run rails db migrate and we need to specify our staging example app here so it knows which to connect to because i have this one app connected to staging and to production so this is going to boot up that command had run it on our staging environment for us it's going to run our migration so we have our to-do list table on that separate database on for sp staging instead of for production and once that is done we can open up our application and we can create our to-do's here and those are going to be separate from the to-do's here for production so if we refresh this and we refresh this they have separate data in them and that shows us the correct information for staging and for production so that works great now let's go ahead and set up a a pipeline so heroku has the concept of a pipeline where you might deploy your application to staging and then promote it to production once you've tested it and made sure that it is functional as needed and then you can go and say okay this is ready go to play to production so for this we'll have our example app pipeline we'll call it that and we'll connect this to the um the application there and so we'll create this pipeline we'll add our staging app we'll have staging example app here and then we'll have production example app on the production side and we can simply set that as sell now we can connect this to github to get some extra features here but i want to show you basically how this works right now we see that the commit for production is a little behind we've made some changes to add that staging environment and we have this promote to production button here and what this will do is basically take the compiled staging application and then move it to the production server and update that it doesn't have to go install any new gems or anything because heroku has compiled an image for us and it just needs to run that new image on the new server it doesn't have to run our asset pipeline or anything like that it can just boot up the new application without rebuilding so if we hit promote that is going to then create a new release and voila we now have a new version in production you're not going to notice any changes here yet because we didn't make any visual changes to the production one we just added some back end code for the staging environment but that is all there is to it so now we can go into say our application.html.erb we want to change maybe the the title um my to-do list and we'll put in here rails.n and what we should see is that we will see development or production or staging or whatever it is in the header so if we make this change we can say get status we'll add the navbar change will push that commit up so add rails in to navbar get push and we can get push heroku master or heroku staging master for that so we'll deploy this copy to the staging environment so once this is done we'll be able to refresh this and we'll see that so we'll wait just a second so now that our deployment is complete we can open up the staging app and refresh and we'll see the staging header in the nav bar and that's great so our changes have been promoted in the production version we haven't updated anything yet so we can look at this and say okay let's approve this and let's make that happen in production so same thing as before we just simply promote to production we don't need to deploy to production because we've already deployed the image and we can just bump that as a new release and it's almost instantaneous so there we go in production we will now see after the app restarts it will take a second but we will see the new changes basically immediately we didn't have to wait for a deploy at all so that's really really cool and a very handy thing now we can also move the app around if we need to or anything like that but generally that is not something you need to do and you're good to go so there we have it we are able to deploy new um releases to staging we can do all our testing there and then we want to promote that to production it's just an instantaneous change to promote and we're good to go so that is how to set up a staging environment on your ruby on rails application you can add more environments here you can also add preview environments with heroku so if you have a pull request you can have a rails app that's just deployed for that one pull request so you can test those changes and delete the app when you're done it's really really cool and very handy but staging is more of a permanent thing that you want always running so you can always test your application

Channel: GoRails

Views: 1,732

Keywords: Ruby, Ruby on Rails, Rails, Javascript, HTML, CSS, Servers, Databases, Screencast, Tutorial, Rails 6, Action Text, Active Support, Action Mailbox, Webpacker, Active Storage, Active Record, rails testing, ruby on rails testing, ruby testing, devise, rails devise

Id: xf0n687EKns

Length: 16min 14sec (974 seconds)

Published: Mon Jul 05 2021