[OH-Dev] Documenting deployment with Heroku

[Asheesh Laroia]

Excerpts from Daniel Mizyrycki's message of Tue Jun 12 19:14:18 -0400 2012:
> Hi Asheesh,
> 
> On 06/11/2012 02:01 PM, Asheesh Laroia wrote:
> > Excerpts from Daniel Mizyrycki's message of Sun Jun 10 15:13:50 -0400 2012:
> >> Hi Asheesh,
> >> Here is what I saw:
> >>
> >> * Heroku cli tools are based on rubi. I thing for the installation
> >> purpose is worth mention to install the package rubygems, and then
> >> install heroku as their instructions only support Debian based systems
> >> for linux. My biggest concern was to install rubi on my system (Centos
> >> 6) but rubygems are a total of 3.2MB of rpm including dependencies! For
> >> Redhat systems would be Something along these lines:
> >>
> >> yum install git rubygems   (just about 3Mb rpms)
> >> gem install heroku
> >>
> > Interesting; I hadn't realized how Debian/Ubuntu-centric the instructions
> > are, for Linux systems.
> >
> > I think it makes sense to document other ways to install the Heroku stuff.
> > I'd much prefer to link to Heroku-written docs on this in general.
> Me too. All I'm saying is that takes time away from people to do what
> they are looking for. Dealing with this 'details' on your own is not 
> much fun.

Yeah, I see what you mean about that not being fun.

Maybe we can create a section called "Troubleshooting" within the
Heroku doc, and then in the "Install the Heroku toolbelt and log in"
section, we might say, "If you don't see instructions for your
operating system, look in this page's Troubleshooting section"

and then within the Troubleshooting section, we could say:

"If Heroku doesn't have instructions for your operating system,
and you have a package manager, try installing "git" and "rubygems"
from your package manager. For example, on Fedora and other systems
that use yum, you could type:

    sudo yum install git rubytems

Then run:

    sudo gem install heroku"

> >> * At last I got:
> >>
> >> # Get the URL of our new website
> >> heroku apps:info --app ohdevel
> >>
> >> ( Application Error
> >>
> >> An error occurred in the application and your page could not be served.
> >> Please
> >> try again in a few moments.
> >>
> >> If you are the application owner, check your logs for details. )
> > Interesting. It really should work at this point. Can you share the logs?
>
> Sure. How?

$ heroku logs

> >> * At this point I realized running migrations is mandatory. Although the
> >> document does mention migration are not running properly, it sorts of
> >> imply the entire procedure will achieve some sort of successful
> >> deployment which I wasn't able to see following the instructions. I feel
> >> we should address the issue either, stating the Heroku deployment
> >> procedure is work in progress, or giving the instructions to achieve the
> >> state where we have a 'temporary deployment where you don't mind erasing
> >> the database later.' I am missing something?
> > Because of a special hack in mysite/settings.py , we disable migrations
> > on Heroku. That means that the 'syncdb --noinput' will create all DB
> > tables, even those that normally would require migrations.
> >
> > (Look for "### If we are running on Heroku" in mysite/settings.py and
> > you'll see what I mean.)
> >
> > I'm going to test these instructions right now, once again, and
> > see if I can replicate your problem.
>
> This is probably old at this point, given that we found a solution. 
> Isn't it?

Er, yes, it is old, and we did find a solution.

> >> * I tried to work in the Heroku environment (with heroku run shell) to
> >> be able to debug what it is  happening. I am perplexed that there is no
> >> vim, nano, and even less! The environment is debian sid. dpkg is blocked
> >> for root use, and it doesn't seem one can become root. Do we need to
> >> upload binaries as part of a deployment for troubleshooting at Heroku?
> > Well yeah, you're not supposed to do much editing of code/setings within
> > Heroku. The key is to get them right from the start with the data that
> > you transfer to Heroku when you do the 'git push'.
>
> Yes. I understand. But the emphasis here is in troubleshooting.
>
> How did you do it?

How I did it was:

$ heroku logs

Notice a weird message about there being no "web" process.

Google that message, and discover that Heroku no longer autodetects
our "manage.py" in the location it's in.

Look up how to indicate how to run the app, and discover the
Procfile system. Create such a Procfile that shows Heroku how
to run the app. Push again, and then find a new error message
about there being 0 web workers. Use 'heroku scale'.

It definitely makes sense to write about "heroku logs" within
a Troubleshooting section, and we can link to the official
Django+Heroku documentation there so that people can read
through how things are supposed to work.

How does that sound?

-- Asheesh.