Cue-to-Cue Dry Run of the Agile Workflow

In theater, a "cue-to-cue" rehearsal is one in which (roughly) only the first and last lines of dialogue in each scene are spoken, because the point of the rehearsal is to practice the technical "cues" that occur between the scenes, such as lighting changes, sound effects, moving props around on stage, and so on. In other words, the rehearsal is about everything except saying the actual dialogue lines. 

Similarly, in this assignment you'll practice the tool-rich Agile/XP workflow by doing everything except writing code and tests (except in the most trivial sense), to practice getting into the rhythm of the various tools used in the workflow.

This assignment is intended to be done with your team using a single shared repo.  Many of the steps can be done in parallel; we suggest reading through the whole thing first and determining when pairs can work in parallel on different steps. Being in constant contact with your team for coordination will help.

Create the app & repo

One person or pair should do these steps:

1. Be sure you have a recent version of Ruby, >= 2.6.6. (Earlier 2.6.x versions have bugs.) You should already have rvm set up from the previous assignment; rvm use 2.6.6 (or a later version of Ruby) before proceeding. Note that versions <=6 of Rails require Ruby <3.0.

2. Run rails -v to ensure you’re running the desired version of Rails. If not, run gem install rails -v x.x.x with x.x.x set to the version you want; we recommend a recent version of Rails 6 or 7. (For this app it won't matter)

3. Next you'll create a super-simple app to use as the placeholder for what would be a real team app. Run  rails new <appname> --skip-spring --skip-turbolinks --skip-test --skip-webpack-install to create the new app. (We recommend omitting the Spring app runner, Turbolinks nonsense Links to an external site., and Test::Unit testing framework, respectively, and only installing Webpack support if you are pretty sure you'll need it, since it also requires Yarn and Node to be installed separately. Note: if you skip Webpack, which we recommend, you must also remove the webpacker gem from the Gemfile and re-run Bundle if it's present, and you must delete the call to javascript_pack_tag in the application layout if it's present, or you'll get startup errors when you run the app. You should also delete config/webpacker.yml if it's present (it shouldn't be unless you tried to start the app before removing the Webpacker gem). Yes, welcome to setting up a new app!

4. cd <appname> to navigate into your new app’s root directory. From now on, all shell commands should be issued from this directory.

5. Check: Make sure your app runs by executing rails serverand visiting the app’s root URI. You should see the Rails welcome page.
6. So far so good. But the app will not actually work in deployment on Heroku unless there is an explicit route for the home page, "/". Add a route for the home page, and a single controller and view for that route. The view should just display the name of one of your team members, chosen at random; you'll add more later. Check: running the app locally and going to its home page now serves that view. 
7. The Rails app creation command automatically sets up your app’s root directory as a GitHub repo. Add the files associated with your app, making sure to exclude log and tmp if it is not already done. (A good exercise: do this by adding those paths to .gitignore, which should itself get added to the repo.)

8. Create a GitHub repo via GitHub’s web interface, and do the initial commit and push of your new app’s repo. Give everyone on your team push access on the repo. Have every team member clone the repo to their local environment. Warning: depending on which version of Rails and your local settings, the default branch of your local repo may be named either master or main. Before pushing, make sure the default branch of the GitHub-created repo has the same name!

Deploy to Heroku

Make the changes necessary to your Gemfile for deploying to production on Heroku:

# make sure references to sqlite3 gem ONLY appear in dev/test groups
group :development, :test do
  gem 'sqlite3'
end 

# make sure the following gems are in your production group:
group :production do
  gem 'pg'              # use PostgreSQL in production (Heroku)
end

1. Run bundle install --without production if you’ve changed your Gemfile. Commit the changes to Gemfile and Gemfile.lock. On future changes to the Gemfile, you can just say bundle with no arguments, since Bundler will remember the option to skip production gems. (A good exercise: In newer versions of rails the  --without flag is deprecated. How would you achieve the same effect?)

2. Normally, when you use Heroku, you would create your own Heroku app. However, in this course offering, we would create Heroku apps for you. Each team should have a Heroku app already created by course staff and the Heroku app name should be communicated to you. You should run  heroku git:remote -a <heroku-app-name> to connect it up to your repo. Use the correct <heroku-app-name> of your group app! Each member of your team should do this connecting step once to ensure their own local repos are all connected to Heroku.

3. Check: Run git push heroku master (or main if that is your main branch)  to ensure the app deploys correctly. Visit the app's home page and verify it behaves the same as locally. (The first time you deploy, it may take several minutes as Heroku needs to install all your gems. Future deploys are faster since only new or changed gems must be installed.)

Set up support for testing

1. Add support in your Gemfile for Cucumber, RSpec, and code coverage, and re-run Bundler to install the gems:

# setup Cucumber, RSpec, Guard support
group :test do
  gem 'rspec-rails'
  gem 'guard-rspec'
  gem 'simplecov', :require => false
  gem 'cucumber-rails', :require => false
  gem 'cucumber-rails-training-wheels' # basic imperative step defs like "Then I should see..."
  gem 'database_cleaner' # required by Cucumber
end

2. If all is well, create the subdirectories and files used by RSpec and Cucumber:

rails generate rspec:install
rails generate cucumber:install
rails generate cucumber_rails_training_wheels:install
bundle exec guard init rspec

Note: the above commands will add a number of files to your app. Make sure you add them in Git. Commit. Push. Deploy to make sure it all still works.

3. Set up SimpleCov Links to an external site. to enable test coverage measurement. (Note: you only need to measure coverage when running your tests—not when your app is actually executing. This will save you a step in the setup instructions for SimpleCov.)

Check: running cucumber and rspec should be error-free, and should generate a file coverage/index.html that you can view in a browser to see your (initially pathetically low) test coverage.

Recommended: explicitly exclude the coverage directory from Git by adding it to .gitignore. For this simple assignment it doesn't matter, but get used to doing this for real repos.

Set Up CI (GitHub Actions) and Code Quality reporting (CodeClimate) 

1. Someone on the team (perhaps the person who owns the team repo) should also sign up for free account on CodeClimate.com (you're interested in the "quality" product, formerly known as "maintainability" product, not the "velocity" product, for CodeClimate). Point CodeClimate at your app's repo. Add a CodeClimate "maintainability" badge to the repo's README so you can always see the latest maintainability score. Strongly recommended: use your GitHub login for these. CodeClimate is removing the email login soon.

2. We will be using GitHub Actions in the assignment. Someone from the team (perhaps the owner of the repo) should create a GitHub Actions by navigating to the Actions tab on the repo page. Following this a window a few suggested workflows (i.e. the CI scripts) will be recommended. You do not want to choose this, instead go through skip this and set up a workflow yourself. Prompted with an online editor, you will need to copy the script from here Links to an external site. and paste it in the online editor. Note: the ruby version in the script should match what you have in your rails app. For instance, if the app is built on ruby 2.7.2, then change lines 10 and 13 in the script to 2.7 and 2.7.2 respectively. This step may take some trial and error. You can tell if CI is working based on a green checkmark next to the commit timestamp. Once you have updated the repo and got the CI to pass make sure to pull all the changes to your local environment.

If setup correctly, the CI repo should always pass. In the script, we are running all the rspec tests, but have written 0 of them. So we pass 0 of 0 tests!

Ensure Heroku deployment still works by redeploying the app to Heroku.

Doing the dry run of an iteration

OK, now you can actually do the dry run!

Here's what you'll do, for each person listed as a collaborator on the Tracker project (will be no more than 4, due to the limitations of free Tracker projects):

1. Create an issue in GitHub Issues associated with your repo, such as "Add my name to the app's home page" (Remember we only have one name there?).
2. One person or pair claims the issue, and creates an appropriately named feature branch in GitHub.
3. Add the (simple) code on that branch, e.g. adding a name or two to the app's splash screen
4. Push the changes to the feature branch, ideally triggering CI & coverage
5. Do a pull request to the main branch once CI & coverage look good. Make sure you mention the issue number in the pull request comments, e.g. "Fixes #35".
6. Get at least one other team member to sign off with LGTM ("looks good to me") in the PR, then merge it and close the PR.
7. Deploy to Heroku one more time from main, and verify that the change is correctly reflected

Try to do this workflow once with each of your team members!

What to turn in

You will need to submit:

1. a link to your Github repository, where we will look at the "conversation" screen of one of your (now closed) PRs, showing that it was opened and closed by different people, as well as the list of merged PRs (we're expecting that each person closes one PR)
2. a screenshot of your app on Heroku at the end of N times through the above workflow

(Use the rich text editor to submit images)