Instead of having to go through a convoluted push process that takes several minutes to complete every time I make a minor change, I'd like direct FTP access to my files on the Heroku server.
Is this possible?
No, it is not possible. While directly pushing with FTP is more simple, it is a fragile means of deploying code and managing applications (hard to track what was done, difficult to reproduce or manage rollbacks, etc).
No, you cannot. Using the Git you can manage different version of your code
As a workaround, you can try to Use Dropbox Sync and deploy your app from Dropbox.
UPD: In July 2018 this feature was deprecated.
Related
For reasons outlined here: https://community.exasol.com/t5/discussion-forum/performance-on-premise-dropping/td-p/9029 we need to restart a database regularly (at least until al issues are resolved, and this can take some time). So the question arises: Can this be done on a regular bases without human interaction?
LUA is not a solution, but perhaps a cron job is possible, but we need OS access for that, which we do not have.
Try to use xmlrpc API: https://github.com/exasol/exaoperation-xmlrpc/blob/master/EXAoperation_XMLRPC.md#method-restartdatabase
Here is a nice example with explanations: https://community.exasol.com/t5/environment-management/starting-and-stopping-clusters-using-xml-rpc/ta-p/1579
Yes, this should be possible using the shudownDatabase() and startDatabase() methods from this GitHub repository. You might need to use stateDatabase() in between to determine when the database is actually stopped before you try to start it again.
What methods would you use to securely use multiple machines to work on code in active development?
My Ideal Situation
Sharing development code securely among multiple machines (at least two)
Automatic synchronization (think Google docs whereby any user's changes update all the others immediately). The reason for this is that I'd like to be able to use these computers interchangeably without having to commit / clone every time I switch. My understanding is that automatic synchronization would make it possible to switch machines seamlessly without having to commit a bunch of files each time.
The location of the development code is such that it can be accessed by a local Rails server and rendered on localhost:3000.
The solution works for Apple machines (both my computers are Apple).
I'm not sure if this question is a 'reasonable' question in terms of its specificity but it's the best first attempt I have. Thanks!
If you are the only person working on this project, then a service like Dropbox would work and provide you with the automatic synchronisation you're after.
However, if you're working with someone else on this project, or you're likely to do so in the future, then it's worth learning the basics of Git (or some other distributed version control system). It's probably not as hard as you expect:
You can get by with a few basic commands (see Everyday Git with 20 commands or so).
You can simplify things even further with git-up (this isn't perfect, but in most cases it makes fetching remote changes into a single command).
There are various OS X GUIs available to help you, including GitHub for Mac and GitX
You can get private repository hosting from GitHub (for a small fee) or from butbucket (for free).
Syncing with Git won't be automatic, but it does give you a lot of flexibility.
use any version control system (guess you do already) and if you really need automatic synchronisation put something like this in your crontab (assuming svn and growl for notifications):
* * * * * cd /path/to/checkout; svn update && svn commit -m '' || (echo "sync failed" |growlnotify )
I think version control is safest best practice for code sharing.
If it is only you working on the code, you can certainly set up another mode of syncing like auto-sync dropbox folder.
Also, if the assumption is you always got your laptop accessible as well when working on desktop, you could just use the actual laptop's code location as a shared network folder on your desktop, so no syncing is needed :)
Dropbox is the best free and easy solution. I use it as well for my personal projects. Only beware to run dropbox on two computers at once when from one pc you sending changes and second one is only running dropbox, you propably loose your work(that was my case).
Just wondering how everyone pushes updates to their production server on Heroku, without bringing the app down for a few couple of seconds?
Pushing to Heroku (especially using something like Unicorn), takes a while for the web app to load. Especially when there are end-users trying to access the site. They end up with 503 pages.It takes up to 30 secs to a minute for Unicorn processes to load.
There are TWO things you need to accomplish this, and it's not trivial.
1) Migrations need to be backwards compatible (i.e., run while the app is live). See this article about that: http://pedro.herokuapp.com/past/2011/7/13/rails_migrations_with_no_downtime/
2) Deploy using TWO heroku apps. I opened a ticket with Heroku on this topic and this was their reply:
We're currently working on a solution to provide a zero-downtime
deploy but do not have an ETA on when this might be available.
In the meantime a workaround that might be possible would be to deploy
to two separate apps. You can push new code to the second app, spin it
up, then move the domain names over to the second app. Wash and repeat
on the next deploy. This is less than ideal but might get you the
desired result in the interim.
If you do this, you will want to automate as much as possible since there's a lot of ways to mess that up. Here's an article on that topic: http://casperfabricius.com/site/2009/09/20/manage-and-rollback-heroku-deployments-capistrano-style/
Why?
These two solutions must both be done because the database migrations must work in BOTH (live and to-be-live) versions of the code. Once you have that working, THEN you can solve the second problem of having the application itself not seem like it went down. There is no supported way to spin up and spin down individual dynos once a push is started.
UPDATE:
There is a beta feature available with Heroku now. To use do the following prior to pushing:
heroku labs:enable -a APP_NAME preboot
This will change the behavior of the app during pushes. It will push up a parallel instance that will warm up for two minutes. Almost exactly two minutes after the push, all traffic will route to the new app. Be careful with migrations, as I mentioned above, as they are still an issue.
Heroku is currently testing their new preboot feature in beta. You might wanna check it out. Unfortunately it only works for ≥2 web dynos. And it also doesn't seem to work for heroku scale web=… which would be important to make it work with HireFireApp.com.
In the past we (a coworker and I) would push our changes directly to master. And then inform each other that changes need to be pulled.
A new coworker suggests forking the git repo and when he makes changes. He does a pull request. I would still be on the master repo and accept the request for the pull.
Which is the traditional / common approach when working together as a team? Or is there a better approach?
It depends on if you want to have one central repository or not. Many organizations have been using and continue using a central repository when they switch to git. It also depends on access, trust and how many developers you are. If you are only a few devs and you all trust each other, I'd go with a central bare repository that everyone pushes to and pulls from. Keep it simple.
If you are 100 developers and perhaps also external developers that you don't trust using your central repo and want to restrict access for some other reasons then pull requests might be the solution.
The important thing is to look at what kind of workflow YOU want and keep in mind that git will not get in your way and will let you decide that for yourself.
The traditional way is to fork-pull, i.e. the Linus-fork of the Linux kernel is the official line. The difference to your current approach is the amount of control you are having over the changes. If you don't need this control or if you can't check the changes anyway because you don't have the time to do so, theres no advantage in pulling manually. Git does handle resets/deletes very good and you can always go back in history.
Forking a git repo is a much better approach when working in a team as it makes sure your repo and code never hit an inconsistent stage. However this practice is not very common in the world. Most teams have made it a tradition where everybody is working on the same branch at the same time, this is a bit dangerous but can be made efficient by adding an email alert sending functionality in the post-receive hook of the repo so that the other team-mates can pull the changes as soon as they get an email alert.
I hope this helps.
I would say there are two main workflows:
As Magnus said everybody is pushing to the "blessed" bare repo, while working on the local clones of it.
More restricted work flow may suggest limited number of people having push access to the blessed repo and all other contributors are either sending pull requests or if the pull is technically difficult they provide patches. But they are pulling from blessed repo to keep their repos in sync. This workflow implies code review by "lieutenants" before the change goes to the blessed repo
Like every commit has a reason and purpose, I think each deploy has a purpose and reason. Source code commits have a comment. But deploying doesn't have any.
How do I record a reason and purpose for each deploy automatically?
I need to keep a record of:
Who deployed to where and what time.
Why deployed? Bug fixes? Feature update? Emergency fix not on iteration plan?
Which git or svn ref was used?
Have anybody felt the need for this kind of system? How do you feel about my approach?
How can I achieve my goal? I'm currently using Capistrano for deployment.
A bounty added. I'd like to hear more stories from different developers who are doing "continuous deployment".
I found two services that do deploy tracking:
Codebase
Hoptoad
Webistrano - https://github.com/peritor/webistrano/wiki - is a web interface to capistrano, that also tracks who's deployed what and when, so that could be worth investigating.
My current project uses a modified version of the apinsein's git-deployment recipe, which (when you tell cap to do a deploy) will tag current HEAD with a Git tag (which gives you all the benefits of normal Git commits).
I've built a web service for this exact problem, http://deploytracking.com, it hooks into capistrano and records the time, user, branch, ref, environment and repo that was involved in the deployment.
Strano - The Github backed Capistrano deployment management UI.
Regarding continuous deployment, I also submitted pull request there, which Introduce automatic deployments for GitHub projects, for now it simply triggers deploy task when somebody push to the master branch.
I don't know if it is still relevant but I would like to come up with a different solution. I am building a new deployment tool that does just what you are looking for.
I do not intend to spam my stuff here but since I am building something that could help you...
Anyway, have a look here https://alessiosantocs.github.io/Captain. I'm gathering feedback so if you have any please let me know.
Update
As suggested, I'm giving an explanation :)
I have also felt this need. I work in a digital startup and we're constantly deploying stuff 5 days a week on different Ruby on Rails application with Capistrano.
What we noticed was that for every single deployment, we should have done several things:
Keep track of which pull requests and commits went online that exact moment
Give some sort of a name to the deploy so we could recognize it
Alert our team members so that everyone could have been on the same page (without asking us of deployment's news)
Keep track of every deployments for future bugs and errors we might find at some point in time (which happened often)
So for this reason we started developing this custom solution that would integrate with Capistrano and our SCM (bitbucket) and keep track of every change we made to our master branch. This is what it does right now.
We are currently tracking deployment environment, repo source, deployment branch and revision. Mainly we manage pull requests, because we found that pull requests, better than commits, did solve an organizational issue in our team (it was difficult to approve other team member's code without a rigid system like PRs)
I would like to explain more about Captain and about our personal dev management strategy with you guys if you want.
Thanks #thirumalaimurugan for asking for clarification!
Update 2
We tried git tagging too. It was good and fun at the beginning but we couldn't manage them very well.
A tag is basically a bookmark to a specific revision. So we're talking about commits. A tag keeps no track of pull requests. It was quite a mess for us.
I don't think they're bad at what you're trying to achieve, but I think there must be some other solutions that could fit exactly your (and our too) problem.