Re: Hosted Rails CI?
On Thu, Aug 19, 2010 at 11:47 AM, Matthew A. Brown wrote: > Hi all, > > One missing element from what is otherwise cloud nirvana is a hosted > continuous integration solution, at least ever since runcoderun closed > up shop. Anyone know of a good one, ideally with a free or very cheap > intro level? Nope, but installing cijoe or integrity takes a couple minutes and not that much hardware, so we use those. > > Mat > > -- > You received this message because you are subscribed to the Google Groups > "Heroku" group. > To post to this group, send email to her...@googlegroups.com. > To unsubscribe from this group, send email to > heroku+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/heroku?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Heroku" group. To post to this group, send email to her...@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
Re: Do you pay for multiple apps, or only multiple dynos per app?
On Mon, May 17, 2010 at 3:44 PM, Brian wrote: > I currently have one app running with one dyno in production env. I'd > like to create a staging one too, but am not sure if I can do that, > with one dyno and its still free, or if I'll now have to pay for a 2nd > dyno. No, you only pay for multiple dynos on the same app. You can have plenty of 1-dyno apps for free. > thanks, > Brian > > -- > You received this message because you are subscribed to the Google Groups > "Heroku" group. > To post to this group, send email to her...@googlegroups.com. > To unsubscribe from this group, send email to > heroku+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/heroku?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Heroku" group. To post to this group, send email to her...@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
Re: Simple staging process -- please check
On Wed, Apr 14, 2010 at 9:06 AM, steven_noble wrote: > Hi all, > > I'm about to set up a staging server on Heroku and I'm hoping you can > check my logic before I do anything stupid. > > At present, I have a production app on Heroku: > > drominay-production > http://drominay-production.heroku.com > http://www.drominay.com > > I am the sole developer. The latest version of the code is on my Mac, > which backs up continuously to TimeCapsule and to Dropbox. I also push > the entire code-base to Heroku whenever I'm happy with the state of > the code: > > git add . > git commit -a -m "here's what's new" > git push heroku master > > So far, I haven't had a reason to teach myself how to branch the code > in git. I just build one feature at a time, commit regularly, and push > the entire code base when it's ready. > > My goals are: > > 1. Continue to store the latest version of the code locally > 2. Whenever I'm happy with the state of the code, push to a new app, > drominay-staging, for a final check > 3. Copy the database from drominay-production to drominay-staging to > ensure the final check is robust > 4. Prevent the public from accessing drominay-staging, while creating > a separate code base > 5. Minimize complications > > Here's what I propose to do: > > 1. Create drominay-staging > > A. heroku create > B. heroku rename drominay-staging --app 77-green-bears-or-whatever- > heroku-names-it-originally > > 2. Lock drominay-staging without creating two code bases > > A. heroku config:add RACK_ENV=staging --app drominay-staging > B. Surround most of declarative_authorization's rules for the > guest role with conditions like 'unless RACK_ENV == "staging"' > > 3. Test the current code and live database on drominay-staging > > A. git push heroku master --app drominay-staging You would have a different remote for the staging app, so you'd actually just do `git push heroku-staging` or something like that. --app is not a valid git switch :) > B. heroku rake db:migrate -app drominay-staging > C. heroku db:pull sqlite://backup.db -app drominay-production > D. heroku db:push sqlite://backup.db -app drominay-staging You should first push production's database to staging, and then run the migrations on staging (so step B should come after step D), or else whatever changes you do to existing tables will be overwritten by the db:push. Also, after doing a rake db:migrate you need to run `heroku restart`. Cheers > 4. Backup live database and then push code base to live app > > A. heroku db:pull sqlite://backup.db -app drominay-production > B. git push heroku master --app drominay-production > C. heroku rake db:migrate -app drominay-production > > If I do this, am I in for any nasty surprises? > > There looks like lot's of opportunities for nasty surprises, so I > guess the next step is for me to turn this into a few trusty rake > tasks. > > Many thanks in advance, > > Steven. > > -- > You received this message because you are subscribed to the Google Groups > "Heroku" group. > To post to this group, send email to her...@googlegroups.com. > To unsubscribe from this group, send email to > heroku+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/heroku?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Heroku" group. To post to this group, send email to her...@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
Re: Streaming files without locking up dynos
On Tue, Apr 6, 2010 at 1:04 AM, Eric Anderson wrote:
> I am having some difficulty trying to figure out how to stream out
> files from Heroku without locking up my dynos.
>
> The basic setup
>
> I am making an app that combines Heroku and Twilio. Part of this app
> involves presenting users with the recordings that have been made on
> Twilio. Twilio provides a URL to these recordings but they don't
> really set the headers right (for the MP3 they don't provide the
> content length messing up some clients and they don't set the content
> disposition to attachment causing some clients to play the file inline
> and not do a very good job at that).
>
> In addition to these headers issues I would ideally like to not give
> out the URL to the recording as it is not protected by any
> authentication.
>
> Attempt One
> ---
> So my first thought was to simply proxy the download through Heroku. I
> figured this would allow me to adjust the headers and hide the Twilio
> URL. The problem with this is that while proxying the file it prevents
> the dyno from handing other requests. I had hoped if I streamed the
> content out (in rails render a block that chunks it out) or by using
> some sort of sendfile header. None of those options worked. I
> contacted support about this hoping there would be a decent solution
> but they said a dyno gets locked up until the file is downloaded.
> There is no way around this. This means that if I get a user on a slow
> modem downloading a file it takes down the dyno. If I get a multiple
> slow people downloading files and don't have enough dynos it basically
> will take down my site. :(
>
> Attempt Two
> --
> So my next thought was to allow them to download from a location other
> than Heroku but still one where I have control over the HTTP headers.
> S3 seemed like an ideal candidate as Heroku runs on Amazon as well. So
> I wrote the code to copy the file from Twilio to S3 through Heroku
> when a download is requested then redirect to S3. This works but not
> well. It still locks up my dyno for about 20 seconds (for a 30 min
> conversation) while copying (most of the time is spent downloading
> from Twilio although some still spent uploading from Heroku to S3).
> Longer conversations would lock up my dynos even longer.
>
> I am trying to avoid pre-sending all conversations up to S3 as I want
> to avoid paying S3 to store the conversations when I am already paying
> Twilio to store them. I don't mind sending them up to S3 for temp
> storage but I need to do it on demand and it looks like they can't be
> downloaded fast enough to make that happen.
>
> So I am looking for suggestions of ways to deliver these files while
> not locking up the dynos. Is there any way to send a file from a URL
> to S3 without having it go through Heroku. Any suggestions in general?
When a user requests a file, put a delayed job to get the file and
upload it to S3, then poll with ajax every 1 or 2s ("Your file is
being prepared…") and then give them the download link to S3 once the
upload is complete. That is relatively easy to do with the heroku
stack and shouldn't lock anything for you. If you get multiple
simultaneous users asking for files, just increase the number of
workers so it speeds up the site for everyone—but again, nothing is
locked, it just takes more time until the file is ready.
Cheers
> --
> You received this message because you are subscribed to the Google Groups
> "Heroku" group.
> To post to this group, send email to her...@googlegroups.com.
> To unsubscribe from this group, send email to
> heroku+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/heroku?hl=en.
>
>
--
You received this message because you are subscribed to the Google Groups
"Heroku" group.
To post to this group, send email to her...@googlegroups.com.
To unsubscribe from this group, send email to
heroku+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/heroku?hl=en.
Re: Healthy Habbits for Huge DataSet
On Fri, Mar 12, 2010 at 12:42 AM, schapirama wrote: > Hi Tobin, > >> Another solution is to create a dedicated Heroku app that holds this >> data, and presents a service that our app can use. This means setting >> up another app, telling the developers about it, managing it, backups >> etc. A bit of a pain really, but it would work in the short term. > > That's definitely the solution I'd pick if I were you: a separate > component with a RESTful API to do the lookups. It will certainly add > the extra latency in the HTTP requests that you have to make, but I > think that the cost is well covered by the extra simplicity, as long > as the interface from this service to the outside world remains > stable. It'd make your deployment and DB migration easier and faster > (as you mention), and simplify development and debugging of your main > app. And you can use memcached to hold the info on the client app to reduce the latency for repeated requests (if it makes sense), so then you pay the nice folks at heroku some money, too ;) > In fact, if this lookup service is generic enough, you may offer it as > a service for other apps running on Heroku that may need it... > > - A > > -- > You received this message because you are subscribed to the Google Groups > "Heroku" group. > To post to this group, send email to her...@googlegroups.com. > To unsubscribe from this group, send email to > heroku+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/heroku?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Heroku" group. To post to this group, send email to her...@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
Re: app keep winding down
On Mon, Feb 15, 2010 at 2:15 PM, sslguy wrote: > Any idea why my app ssltools.com keeps winding down. When I visit the > site, I at first get an error code 500. Upon immediate refresh, the > app comes up. However, wait a period of time, and Heroku shuts the app > down. Then the cycle repeats itself. > > Any idea would be appreciated. > Free app? Free apps act like that, if you pay for it then it shouldn't do that, AFAIK. Cheers > -- > You received this message because you are subscribed to the Google Groups > "Heroku" group. > To post to this group, send email to her...@googlegroups.com. > To unsubscribe from this group, send email to > heroku+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/heroku?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Heroku" group. To post to this group, send email to her...@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
