Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expose harness to allow control of hot reload #758

Open
JaTochNietDan opened this issue Oct 9, 2014 · 7 comments
Open

Expose harness to allow control of hot reload #758

JaTochNietDan opened this issue Oct 9, 2014 · 7 comments
Labels
priority-could when we have free time status-planning Active planning underway topic-runtime
Milestone

Comments

@JaTochNietDan
Copy link
Contributor

Hey, I think it would be of great benefit if there were a way from within your Revel application to force a hot reload. If a function were exposed for this, we could then write some logic for an update process within the app itself.

@ghost
Copy link

ghost commented Oct 12, 2014

Hey, @JaTochNietDan, could you please provide some use-case?

@ghost ghost added the status-planning Active planning underway label Oct 12, 2014
@ghost ghost added this to the v0.12 milestone Oct 12, 2014
@JaTochNietDan
Copy link
Contributor Author

Well for example, we could add logic to the application itself so when you make a call to a route such as /update, the application will then pull updates, run a series of tests and then once all of that checks out, then we can tell Harness to do a hot reload of the code base.

This allows us a simple way to roll out updates to the server with our own logic implemented. You could argue that you could just abstract this logic out into a build server of some sort, but for simplicity and convenience sake, this could be a worthwhile addition.

@atomical
Copy link

I started out deploying code with puppet but I knew that probably wouldn't last forever. Next, I built a small ruby script that builds, copies over the files, and runs commands to deploy and restart the process. What you describe sounds really interesting from an application deployment perspective, but I can't think how it would be a good fit for me because I run revel as a rack server with nginx. With multiple rack servers I will be able to copy the new version and have a zero downtime deploy. Is it possible to achieve zero downtime with your solution?

Others may be deploying revel without something in front of it, but I find the configuration and performance options (think achieving 100% with Google Pagespeed) necessary.

@pushrax
Copy link
Contributor

pushrax commented Oct 13, 2014

What we do on mods.io is sit nginx in front, and then dynamically set up ports to load balance on. Ideally when #690 gets into its final state, it will be the easiest way to do zero downtime restarts.

@JaTochNietDan
Copy link
Contributor Author

Hey @pushrax, could you go into more detail about your deployment process?

@brendensoares brendensoares modified the milestones: v0.15, v0.12 Oct 27, 2014
@brendensoares
Copy link
Member

I've pushed this back to v0.15. This may not be a straight forward task and will likely need a cross-platform signaling solution (as mentioned in other issues involving SIGINT on Windows).

@ghost
Copy link

ghost commented Nov 6, 2014

There are such projects in Python. For example, Github-Auto-Deploy or Git Play (both are one file solutions). I think it can be actually easily done in Revel. It should listen on some port and pull request when it gets hook from git's X branch. Illustration from Github-Auto-Deploy's README:
GIthub-Auto-Deploy Workflow
It can even parse .travis.yml file and follow the steps there (we can use docker somehow). The most difficult part is restarting itself (harness is not included in deployed apps, right?); if only it is not started as a separate app (process).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority-could when we have free time status-planning Active planning underway topic-runtime
Projects
None yet
Development

No branches or pull requests

6 participants