<!– Automatically generated by Pandoc –> ." Automatically generated by Pandoc 3.1.8 ." .TH “gemstash-deploy” “7” “October 25, 2015” “” “” .SH Deploying Gemstash Bundler is here for the rescue to keep Gemstash up to date! Create a f[CR]Gemfilef[R] pointing to Gemstash: .IP .EX # ./Gemfile source [dq]https://rubygems.org[dq] gem [dq]gemstash[dq] .EE .PP Then f[CR]bundlef[R] to create your f[CR]Gemfile.lockf[R]. When you are ready to upgrade, simply f[CR]bundle updatef. You may need to run f[CR]gemstashf[R] via f[CR]bundle execf. Alternatively, you can f[CR]gem uninstall gemstashf and f[CR]gem install gemstashf when you want to upgrade. .PP Gemstash will automatically run any necessary migrations, so updating the gem is all that needs to be done. .PP It is probably wise to stop Gemstash before upgrading, then starting again once you are done: .IP .EX $ bundle exec gemstash stop $ bundle update $ bundle exec gemstash start .EE .SS Monitoring Health monitoring is built in to Gemstash using the server_health_check-rack (github.com/on-site/server_health_check-rack) gem. If you request f[CR]/healthf from your Gemstash instance, you will get a JSON response along with an HTTP status code indicating success or failure. The JSON response will look something like this for a success case: .IP .EX {

\[dq]status\[dq]: {
  \[dq]heartbeat\[dq]: \[dq]OK\[dq],
  \[dq]storage_read\[dq]: \[dq]OK\[dq],
  \[dq]storage_write\[dq]: \[dq]OK\[dq],
  \[dq]db_read\[dq]: \[dq]OK\[dq],
  \[dq]db_write\[dq]: \[dq]OK\[dq]
}

} .EE .PP This request will test storage and database access and report on the result. Each key in the status can be requested alone to just report on that status. For example, if you would like a health check that doesnt interact with storage or the database, you can use f[CR]/health/heartbeatf which will always respond with a success while your Gemstash server is running. .SS Downgrading It is not recommended to go backwards in Gemstash versions. Migrations may have run that could leave the database in a bad state.