This is the website for studs, which can be found at here.

Install the latest version of ruby 2.* and the latest 3.* version of rails.

# Install all gem dependencies through bundle (optionally skipping gems required in production)
bundle install --without production

# Create a database configuration (uses a SQLite3 database by default in dev environments)
cp config/database.yml.dist config/database.yml

# Initialize the database (create tables and stuff)
bundle exec rake db:setup
# Write down the admin password output by this command

# Start the server
rails server

Open up localhost:3000 in your favorite browser and verify that it works. You can now login using the credentials of rake db:setup.

PDF Resumes are generated through the pdflatex command line tool. The LaTeX template depends on multiple packages which will probably require you to install additional stuff for the pdflatex compatible tools you use.

• Ubuntu: sudo apt-get install texlive-latex-extra texlive-lang-swedish.

The server is hosted on webfaction. The login credentials can be found in shared Google Doc. For problems with Webfactional refer to their documentation.

The configuration file for the database can be found in

/home/studs/webapps/PROJECT/shared

Deploying can be done either to the staging server or the production one. For the general configuration see

config/deploy.rb

The staging server is deployed to using

bundle exec cap deploy

The staging-specific configuration can be found at

config/deploy/staging.rb

The code will be pulled from the be the master branch and the command to run is

bundle exec cap production deploy

The production-specific configuration can be found at

config/deploy/production.rb

• The master branch should always be up to date, that is it should at any given time be possible to deploy the code to the live server.
• The staging branch should only be used as the final step to verify all code works in production mode on the server.
• The dev branch is the one where finished featues and changes should be added.

Below is the workflow to use when developing. The workflow ensures that the staging and master branches remain up to date, and in sync with each other.

When adding a new feature develop it on a separate branch.

# Create a new branch (make sure you are currently on the dev branch when doing this)
git checkout -b branch-name

# Do your edits on the branch, committing and pushing them

# When you are done switch back to the dev branch
git checkout dev

# Then merge your branch into the dev one
git merge branch-name

When a new release is deployed always verify it works on the staging server first.

# Switch to the staging branch
git checkout staging

# Merge dev branch into staging
git merge dev

# Deploy your code
cap deploy

# Verify everything works on the server

# Now switch to master and merge the staging branch into it
git checkout master
git merge staging

# Deploy your code to the production server
cap production deploy

When a new release is deployed always verify it works on the staging server first.

# Switch to the staging branch
git checkout staging

# Add the code necessary to fix it

# Deploy your code
cap deploy

# Verify everything works on the server

# Now switch to master and merge the staging branch into it
git checkout master
git merge staging

# Deploy your code to the production server
cap production deploy

# Merge the staging branch into dev to ensure both are up to date
git checkout dev
git merge staging

• Martin Barksten <[email protected]>
• Per Classon <[email protected]>
• Victor Hallberg <[email protected]>
• Jonas Sköld <[email protected]>