[OH-Dev] Documenting deployment with Heroku

[Daniel Mizyrycki]

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.

>
>> * 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?

>> * 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?

>
>> * 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?

>
>> I am very pleased at the speed the Heroku deployment went so far and
>> look forward helping this procedure works as advertised.
> (-: !
>
> -- Asheesh.
> _______________________________________________
> Devel mailing list
> Devel at lists.openhatch.org
> http://lists.openhatch.org/mailman/listinfo/devel
>