From Chaos to Collaboration: Improving Your Bootcamp Project Workflow

What this Covers

  • Common difficulties with building bootcamp projects
  • Improve your project planning and progress tracking
  • Automate Deployments to Heroku
  • Protect your main branch
  • Rails testing!
  • Tests and Github Actions

The Stack

Ruby on Rails

Common Difficulties with Bootcamp Projects

Bootcamp project teams typically face a number of challenges that can make completing the project more difficult. Some of the most common challenges include:

Improve your project planning and progress rituals in bootcamps

Definition of Done

By far the most important piece of advice in this blog from bootcamp experience is having a clear definition of done for each piece of work, it should look something like this:

A Better Kanban

Basic Kanban
Improved kanban

Automated Deployments With Heroku

Now that as a team you’ve agreed on a workflow, what can you do to enable the team to follow that workflow even when under pressure? Firstly we have to understand that even though there are benefits, if a process is difficult to follow it’s unlikely the team will reliably follow that process. We can start with automating deployments.

Why you should automate your deployments in bootcamps

Speed and efficiency, consistency, simplicity and flexibility. With Heroku’s automated deployment process, developers can quickly and easily deploy their application without worrying about the technicalities of the deployment process. Additionally, the deployment process is consistent, reducing the risk of errors. Heroku’s automated deployment process saves time and improves the efficiency of the development process, making it an ideal option for developers of all skill levels.

How to automate your deployments

  • Connect your code repository to your Heroku application by navigating to your app dashboard on the Heroku website and selecting the “Deploy” tab.
  • Choose the deployment method that best suits your needs. Heroku offers several options, including GitHub integration, Dropbox integration, and Heroku Git.
  • Configure your deployment settings, such as the branch to deploy and any necessary environment variables.
  • Enable automatic deploys if desired. This feature will automatically deploy your app every time you push changes to your connected repository.
  • Set up automatic scaling for your application, if needed, using Heroku’s built-in features or add-ons.

Protect your main branch

Now that you are automating deployment on each merge to main, protect the main branch from being directly pushed to without going though the pull request process. This will mean every piece of code will be seen by at least one other team member, improving the team’s knowledge of the codebase and enforcing the PR process.

What is branch protection?

Branch protection is a feature in Git-based version control systems, such as GitHub, that allows repository administrators to enforce certain rules and safeguards for specific branches. The purpose of branch protection is to prevent unauthorised changes, reduce errors, and ensure code quality by enforcing best practices for collaborative development.

  • Requiring status checks to pass (such as automated tests) before merging changes
  • Restricting who can push changes to the branch (such as only allowing certain users or teams)
  • Restricting who can merge changes to the branch (such as only allowing administrators)
  • Restricting who can delete the branch (such as only allowing administrators)
  • Requiring signed commits or specific commit message formats
  • Enforcing certain code quality standards (such as preventing commits that fail code linting checks)

How to protect your main branch

To protect the main branch in GitHub, you can follow the steps below:

  1. In the left-hand sidebar, select “Branches.”
  2. Under “Branch protection rules,” click “Add rule.”
  3. In the “Branch name pattern” field, enter “main” (without the quotes).
  4. Under “Require pull request reviews before merging,” select the checkbox.
  5. Under “Require status checks to pass before merging,” select the checkbox.
  6. Under “Include administrators,” select the checkbox.
  7. Click “Create” to save the branch protection rule.

Rails Testing

We have automated deployments so as a developer in a project team or bootcamp I can deploy a feature to production and manually test it as soon as it’s merged. But as our app grows bigger it becomes harder and harder to manually test the entire app and make sure we are not breaking features as we’re building new ones. This is where automated tests come into play; we can write tests and run them at any time to check that the app is working as intended.

Unit Tests

Unit tests are used to test individual pieces of code in isolation, such as methods or classes. They are usually fast and don’t require a full Rails application to run. Unit tests are typically written using Minitest or RSpec, and are located in the test/models directory. They can be used to test the behavior of models, controllers, and other parts of the application.

# test/models/user_test.rb
require 'test_helper'

class UserTest < ActiveSupport::TestCase
  test "full_name returns first and last name" do
    user = User.new(first_name: "John", last_name: "Doe")
    assert_equal "John Doe", user.full_name
  end

  test "full_name returns only first name if last name is blank" do
    user = User.new(first_name: "John", last_name: "")
    assert_equal "John", user.full_name
  end

  test "full_name returns only last name if first name is blank" do
    user = User.new(first_name: "", last_name: "Doe")
    assert_equal "Doe", user.full_name
  end
end

Request Tests

Request tests, also known as integration tests, test the behavior of the application’s controllers and views as a whole, by sending requests to the application and verifying the responses. They test how the application responds to HTTP requests, and can help ensure that the application’s URLs, routes, and views are all functioning as expected. Request tests are typically written using Minitest or RSpec, and are located in the test/controllers directory.

# test/controllers/users_controller_test.rb
require 'test_helper'

class UsersControllerTest < ActionDispatch::IntegrationTest
  test "index responds successfully" do
    get users_path
    assert_response :success
  end

  test "index displays a list of users" do
    user1 = users(:one)
    user2 = users(:two)
    get users_path
    assert_select "table tr" do
      assert_select "td", user1.email
      assert_select "td", user2.email
    end
  end
end
$ rails test

System Tests

System tests, also known as end-to-end tests or acceptance tests, test the behaviour of the application as a user would experience it, by simulating user actions such as clicking links and filling out forms. They test how the application works from end-to-end, including its JavaScript behaviour and interactions with external services. System tests are typically written using a tool like Capybara, and are located in the test/system directory.

# test/system/sign_up_test.rb
require "application_system_test_case"

class SignUpTest < ApplicationSystemTestCase
  test "user signs up successfully" do
    visit new_user_registration_path
    fill_in "Email", with: "test@example.com"
    fill_in "Password", with: "password"
    fill_in "Password confirmation", with: "password"
    click_on "Sign up"
    assert_selector "div", text: "Welcome! You have signed up successfully."
  end

  test "user receives error message with invalid email" do
    visit new_user_registration_path
    fill_in "Email", with: "invalid-email"
    fill_in "Password", with: "password"
    fill_in "Password confirmation", with: "password"
    click_on "Sign up"
    assert_selector "div", text: "Email is invalid"
  end
end

Tests and Github Actions

Even though we have testing that can be run easily with a single command, we need to make sure that this testing is happening automatically and is acting as another line of protection for our main branch. We’re going to automate the tests running on each pull request and merge to main, if the test don’t pass you can’t merge. This means rather than finding out you have a bug in production you will likely find out when the test fails and resolve it locally. This keeps your production environment in the bootcamp more stable and makes debugging easier.

  1. Define the trigger for the workflow, such as push or pull_request, and specify the branches to watch.
name: Rails Test
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v2
      - name: Set up Ruby
        uses: ruby/setup-ruby@v1
        with:
          ruby-version: 3.0
      - name: Install dependencies
        run: bundle install --jobs 4 --retry 3
      - name: Run tests
        run: bundle exec rails test

Conclusion

Although these tools and techniques take a small amount of time to set up, in the competitive microcosm of a bootcamp you may feel like you’re lagging behind other teams when precious developer time is spent implementing them. However, this will reap huge dividends as your project proceeds as you’ll be spending less time debugging and you’ll have more bandwidth for the important things like figuring out how to improve your platform.

To find out more about agile, click here.

Similiar Articles

JOIN THE COMMUNITY

Sign up today for monthly newsletters containing:

  • News and insights from your industry
  • Relevant thought leadership articles
  • Engaging video content
  • Notifications of our upcoming events
  • Networking opportunities with C-Suite leaders