Software dependencies and versions being used:

• Ruby version: 3.2.1

• Rails version: 7.0.4.2

• PostgreSQL: 15.2

The following table lists the features/services our application will include and the best corresponding solution(s) available.

Ultimately, the best solution we select for our Rails app will depend on several factors:

1. Pricing
2. Ease of use
3. Team member experience
4. Robustness

All features, bug fixes, documentation changes, and feedback should be done within the GitHub Repo as either a separate PR (Pull Request) or Issue.

Use the following templates when creating:

• A new PR. Note: More information on Pull Requests can be found in Part 1 and Part 2 in this blog.
• A new issue Note: More information on Issues can be found in this post

Moreover, commits must be managelable in size for effective code review and debugging that can be conducted by at least one other team member.

For example, let's say a team member implements the following changes:

1. Generate a new scaffold
2. Modify another existing model
3. Fix a bug in a view file

Each of these changes should be a separate commit and these commits need to be made in the appropriate branches.

Do not put all changes in one large commit!

Do not make all commits in just one generic branch, especially the main branch!

Each commit message should start off with the appropriate GitEmoji at the beginning of the message line. While not an absolute requirement, this can help all team members, including the individual who created the original commit, to navigate the commit history as the project increases in size and complexity.

We'll be using the popular RDBMS PostgreSQL (via pg gem), along with ActiveRecord as our ORM, and ActiveStorage for managing file uploads.

• Database creation:

rails db:create

• Database initialization:

rails db:migrate db:seed

• Perform all tasks: create, load schemas, and seed all databases:

rails db:setup

• Drop local database (i.e., will have to create, migrate or load schema(s), and seed database(s) again):

rails db:drop

• To see list of all available Rails tasks, use:

rails -T

We'll be using the Pay gem to enable payment processing through Stripe.

Instructions for installing stripe-cli can be found here: https://stripe.com/docs/stripe-cli

Listed below are a few basic Git commands: Note: More commands can be found either on Atlassian's Git Tutorial or other sources by searching Google.

• See current status of all modifications to tracked and untracked files:

git status

• Add (i.e., save) all changes to the current stash for committing:

git add .

• Commit all changes added to the current stash (see previous step).

git commit -m "COMMIT MESSAGE"

Note: The commit message must be added using double-quotes.

• Switch to another branch:

git checkout branch_name

Note: Use -b flag to create a new branch and switch into it.

• Push all Git commits and changes to the remote repositry:

git push origin BRANCH_NAME

• Used to fetch and download content from a remote repository and immediately update the local repository to match that content:

git pull <remote>

• Undo local private changes:

git reset

• Undoing shared public changes

git revert

• Install gem(s) in Gemfile:

bundle install

• Update gem(s) in Gemfile:

bundle update

• Install all packages listed in package.json:

yarn install

• Install specific package that will be added to package.json:

yarn install PACKAGE_NAME

• Upgrade all packages listed in package.json:

yarn upgrade

Note: Yarn uses upgrade whereas Bundler uses update.

• Return list of all Rails routes:

rails routes

• Return list of Rails routes containing specified substring:

rails routes | grep SUBSTRING

• Launch Rails console:

rails c

Note: Useful for running permanent changes, like purging all ActiveStorage records:

ActiveStorage::Attachment.all.each do |attachment|
  attachment.purge
end

• Launch Rails console in sandbox mode:

rails c --sandbox

Note: Running any code in a normal console session will make permanent changes to your local development environment. Conversly, running any code in a sandbox console session will undo all changes, as any modification made during a sandbox session will be reverted when the sandbox session is closed.

We'll be using the Minitest framework for testing our code via TDD.

• Run entire test suite:

rails test

Because we're working in a team with four members, we should ideally use some form of continuous integration/deployment pipeline (i.e., CI/CD pipeline).

CI/CD pipeline information coming soon.

There will be several unique branches in our project's GitHub repo that will have strict rules in place for merging commits or branches:

• main - This is the main branch and essentially will serve as our main-development.
• main-production - This branch will contain code merged from main only and this branch will be deployed to our production environment each time a new merge from main is introduced.
• main-staging if necessary.
• main-test if necessary.

More deployment information coming soon.