Deployment tips

Ruby Apps Radiant CMS
1

I have built a radiant-based site and will soon be ready to deploy it.

I’m looking for advice on best practices. I was not able to find much
about this in the documentation.

Most of the issue is the database. I want to be able update content in
a copy of the site running on my development machine. Then, when I’m
satisfied everything looks right, dump the database and import it into
the production database running on the server.

Some content is stored in files. For example, the Page Attachments
extension stores uploaded images in files (at least by default). I need
to be able to update these files remotely.

Are there existing rake tasks for this sort of thing?

Thanks,
Errol

2

If you are using mysql, I have written a custom extension that does a
lot of what you want. It would need to be tailored a little for your
environment, but I could email you a copy of it if you are interested.

Jamey C.

3

Jamey,

Yes – I’d love to see it.

Thanks,
Errol

4

Jamey C. wrote:

If you are using mysql, I have written a custom extension that does a
lot of what you want. It would need to be tailored a little for your
environment, but I could email you a copy of it if you are interested.

Of course, Jamey added a bit about this extension to Summer Reboot:
http://wiki.radiantcms.org/Migrating_from_SQLite_to_MySQL

Based on this experience, I hope that you can add a bit to Summer Reboot
about deployment issues.
Cheers,
Mohit.
9/30/2008 | 9:36 AM.

5

Ooops!! That’s what I get for answering e-mails just after waking up!
That was actually Christopher D.; sorry guys!

Errol, you can take a look at the link below to see if that extension
helps you any.

Cheers
Mohit.

6

Mohit: Thanks for the link. I’ll take a look at that. Once I get this
site ‘live’ I’ll be happy to document the experience.

Jamey: I’m still interested in seeing what you have done as well.

7

Hey Errol?!

On Mon, Sep 29, 2008 at 11:41 PM, Errol S. [email protected]
wrote:

I have built a radiant-based site and will soon be ready to deploy it.

“thin” and “nginx”. Take a look at the file system (should be
something like XFS, JFS, Ext3 or ReiserFS). Nginx can do all that
stuff yslow is complaining about (etags,… stuff). Do not use
anything else than a B*Tree-Filesystem…

There are tons of so called “Rails hosters” out there. DO NOT listen
to them - mostly scam. What you need are those old-school hosters.
Nobody cares about your rails installation, but when it comes to DNS,
load balancing, storage (SAN without a real filesystem means nothing)
and so on, you gonna need really experienced hosters.

Check out Level3 or something like that.

Andreas

8

On Mon, Sep 29, 2008 at 2:41 PM, Errol S. [email protected]
wrote:

I have built a radiant-based site and will soon be ready to deploy it.

I’m looking for advice on best practices. I was not able to find much
about this in the documentation.

Most of the issue is the database. I want to be able update content in
a copy of the site running on my development machine. Then, when I’m
satisfied everything looks right, dump the database and import it into
the production database running on the server.

Here’s the code from the model of my little publisher extension. It’s
not quite ready for releasing yet, but it should give you an idea.
This assumes your dev database is on the same host as the production
database. And that you’re using postgres. :smiley:

Note: I have some tables (the event ones) that you won’t have, so you
can remove those.

Puts data from the development database into the production one

(by deleting the production tables and recreating them and filling

them with production data.

Note: Obviously won’t work with enforced database foreign keys,

so don’t make them.

TODO: Also copy over user-provided photos from the dev env to the

production one
class Publisher
TABLES = %w( events event_options users page_parts pages layouts
snippets )
def self.publish!
table_string = TABLES.map { |t| "-t #{t} " }
data = pg_dump #{current_dev} -a #{table_string}
pg = IO::popen(“psql #{current_prod}”, “w+”)

pg << "begin;"
  TABLES.each do |table|
    pg << "delete from #{table};"
  end
  pg << data
pg << "commit;"

end

private

def self.current_dev
config = Rails::Configuration.new
config.database_configuration[“development”][“database”]
end

def self.current_prod
config = Rails::Configuration.new
config.database_configuration[“production”][“database”]
end

end

9

Nope. That wasn’t me.

Jamey

10

If possible, I want to NOT assume that I am using a particular database
and that the development and production databases are on the same
machine.

I have started playing with the import_export extension
(http://github.com/radiant/radiant-import-export-extension/tree/master)
to see if it could help form the basis of my deployment strategy.

I have run into a problem, however, and I wonder if anybody else has
tried this. It appears to not work well with the styles_n_scripts
plugin.

Here are the steps I used to try this on my dev machine:

  1. mysqldump -u root mysite_production > mysite.sql
  2. rake production db:export TEMPLATE=db/export.yml
  3. rake production db:drop
  4. mysqladmin -u root create mysite_production (db:create fails for
    reasons documented elsewhere on this forum)
  5. rake production db:import TEMPLATE=db/export.yml

The result is that the site is unable to use the stylesheet I stored
using the styles_n_scripts plugin.

It is interesting to note that the tables created by the
styles_n_scripts plugin appear to be there, and my stylesheet appears to
be in the database – with one missing attribute.

I used mysqldump to back up the newly imported version of the database.
Diffing the original mysqldump (working) and new mysqldump (non-working)
output reveals this:

INSERT INTO text_assets VALUES
(1,‘Stylesheet’,‘stylesheet.css’,‘…snip…’,‘2008-07-10
21:23:37’,‘2008-07-30 02:18:06’,1,1,87,NULL);

INSERT INTO text_assets VALUES
(1,NULL,‘stylesheet.css’,‘…snip…’,‘2008-07-10 21:23:37’,‘2008-10-02
21:00:10’,1,1,87,NULL);

Notice the NULL second field in the imported, non-working database.
This second field is ‘class_name.’

The problem appears (to me at least) to be with the import, not export.
Notice that the missing field does indeed appear in the export.yml file:

TextAssets:
“1”:
class_name: Stylesheet
updated_at: 2008-07-30 02:18:06 Z
updated_by_id: 1
filter_id:
lock_version: 87
id: 1
created_by_id: 1
filename: stylesheet.css
content: |-
…snip…
created_at: 2008-07-10 21:23:37 Z

So, any ideas?