- Where should I write my code?
- What if I need a different version of Spree?
- How should I manage my images?
- What other ways can DevCamps manage my product images?
- How should I manage data?
- How should I manage changes to my web server configuration?
- How do I give my client access to a camp?
- Why is the initial page load so slow?
- How do I test running in RailsEnv production mode?
- Where are my camps?
- How do I restart everything?
- How do I know if it’s safe to remove a camp?
Following good Spree conventions, you should put your code under vendor/extension/site. For example, if you want to create a new view called stretch, you could create
Consult the Spree documentation, but a quick method to change Spree versions is to first clone a version of Spree to a location, then create a symlink between vendor/spree and the clone; for example, to set camp20's version of spree to be based off 0.6.0:
$ cd ~ $ git clone https://github.com/spree/spree spree-core $ cd ~/camp10 $ ln -s ~/spree-core vendor/spree $ re --all # restart camp10 $ cd ~/spree-core $ git checkout -b my_new_feature 1.3.2 # branch from specific release # ... make changes
Images and other binary objects that are used for your site's layout and presentation can normally be stored in Git along with the rest of your code.
Product images may be a separate case, and may be managed several ways, depending on how you want to handle your workflow. Directories containing product images can be managed by DevCamps via rsync. When a new camp is created, or refresh-camp --files is executed, DevCamps will rsync the public/assets directory from the production instance to your camp. This copies your product images so that your camp looks just like your live site.
You may want to add new products to a camp before adding them to your live site. When it's time to promote these changes into production, you'll need to copy the product images into the live site yourself, before migrating the product data.
The default configuration of copying product images over from the live site to camps is appropriate for many projects, but some developers may find other arrangements more appropriate. Two popular alternatives are creating symbolic links instead of copying the files, and storing all files in Git.
Some stores may have thousands of product images, or many at high resolution. To save disk space, these projects may configure DevCamps to create symbolic links from your camps directly to the product images in the production instance instead of copying them. Like using rsync, these symlinks provide your camps with the resources necessary to serve an exact copy of your production site. However, because camp users cannot write to the live site, you may be unable to upload new product images into camps. Or you may use a cloud storage service such as Amazon S3 and just point to the images there.
File management is configured by the copy-paths.yml file, found in your camp type's base directory (/home/camp/spree/ by default.) The default file contains a single entry, and looks something like this:
--- source: /home/spree/live/rails/spree/public/assets target: public/ default_link: 0 always: 1
The source line points to the directory whithin the production instance that you'd like DevCamps to synchronize to camps for you. The target line specifies a relative path within each camp. Set default_link to 1 to use symlinks; rsync will be used to copy files if default_link is set to 0.
Some stores may use only a handful of product images that change frequently, and would like to store revisions of them. Developers of these sites may opt to keep all product images in the same version control repository that stores the rest of the site. This leverages many of the advantages of version control for these files.
To store product images in your project's Git repository, remove the public/assets entry from the .gitignore file at the root of your repository. Then git add and git commit your product image files as you would any other. Once these changes are committed and promoted to production, you'll want to instruct DevCamps to no longer handle these files itself. You can do this by removing the entry from copy-paths.yml, or even removing that file entirely.
As Spree is a Rails application, you should use migrations to manage schema changes. If you need to create a set of initial data, you can either use the daily snapshot of your production database that is provided via the DevCamp environment: refresh-camp --db, or you can create a rake bootstrap task -- you can see how the Spree demo is loaded (via rake db:bootstrap) in lib/tasks/database.rake.
Web server configuration changes will need to be made in three places, in order:
- Your camp directory’s httpd/ subdirectory
- The system's production configuration in /etc/httpd/
- Configuration templates for all camps at /home/camp/spree/etc/httpd/
Inside these directories you'll find the main httpd.conf which stores general configuration and initializes modules, and other files in conf/ and conf.d/ which handle specifics of the site and the behavior of modules, including Passenger. Test changes to these files within your camp first. Once your changes have been approved, you’ll need to merge them into the production and camp template configurations. (There are some necessary differences between the production and camp configurations, so a simple copy won’t work. Make a backup copy of your production configuration before changing it!)
Existing camps may be updated by executing refresh-camp --conf. Note that this command will also refresh database configuration files, and others specified in /home/camp/spree/camp-config-files.
Take a look at the Firewall FAQ.
When using Unicorn, the startup is also slow, but happens right when you start the camp, usually before your first web request is made.
If you're using Passenger to host the application, the first time it is accessed, Passenger needs to start up the Rails environment and load your application. This can be time-consuming, especially when you are running in Rails’ development mode (which is the default for all camps). You can set your Rails mode to be production if that is appropriate.
An additional optimization is to tweak the Passenger setting PassengerPoolIdletime.
Edit httpd/conf/sites/default-vhost.conf and change RailsEnv to production
The files for your camps are located in your home directory. Each camp has a number associated with it. For example, user jon’s home directory has three camps:
$ ls /home/jon camp21 camp22 camp23
The web sites for these three camps are (assuming the VPS hostname is v99.spreecamps.com):
and the index page for these (i.e., the page that lists the camps) is at http://camp.v99.spreecamps.com:8080/.
re --all will restart the web server, application server, and database server.
For your code, you can use git status. If you’ve made database schema changes, you need to make sure that you have created appropriate migrations. For actual data changes, you may need to dump and load as appropriate (or write a rake task to handle it). The rmcamp command will remove a camp for you; for example, to remove camp17:
$ cd $ rmcamp --number 17 Service httpd stop... /usr/sbin/httpd -d /home/steven/camp17/httpd -k stop Service db stop... pg_ctl -D /home/steven/camp17/pgsql/data -l /home/steven/camp17/pgsql/tmp/pgstartup.log -m fast -w stop waiting for postmaster to shut down..... done postmaster stopped rm -rf /home/steven/camp17 Removing entry from master camp database Done deleting camp17