Logistics

• Technical Presentations

Hands on Heroku for Sinatra

• Heroku is one of many “cloud app platform”
• We are going to deploy our app to Heroku

Assumptions

• You have a working Sinatra application
• The code is in a PUBLIC github repository
• Note, you will need to make a few small changes to ready it for Heroku

Setup

• Go to Heroku
• Create a new user account (free)
• Install the Heroku CLI for your platform

Prepare your sinatra app

• go to your local directory containing the sinatra app
• Use Heroku command line to create a new
• The name of your app is assigned automatically and printed out once you do heroku create

Prepare your application

• Configure it for rack: make sure you have a config.ru

Create it on Heroku

heroku create
git push heroku main
heroku run rake db:migrate
heroku run rake db:seed
heroku open

Directly pushing from Github

Heroku has built-in function for deploying changes directly from Github to your Heroku app. This tutorial will go through how to set it up.

Step 1: Connect Github repo to Heroku

Note: Skip this step if you already connected the Github repo to Heroku.

Click “Connect to GitHub” using an account that either owns the project repo, or has contributor access to the repo.

Step 2: Choose the correct repo

Note: Skip this step if you already connected the Github repo to Heroku.

Click “Connect” to the project repo. E.g. hojulian/ruby-getting-started.

Step 3: Enable Automatic deploys

To tell Heroku to deploy on new code changes, enable “Automatic Deploys”.

Choose the branch where the newest changes are located (this is usually main). And click “Enable Automatic Deploys”.

This will enable automatic deployment on the Heroku side.

Step 4: Deploying for the first time

Note: Skip this step if your project is already up and running on Heroku

Since your app is deployed yet, you will need to manually deploy it for the first time.

Click “Deploy Branch” and Heroku will pull the latest copy of your project and deploy it!

On success, you will see a green tick next to “Deploy to Heroku”. If it failed, check the Build logs for any errors.

Continuous Integration and Deployment

• Objective 1: Make sure that bugs are detected as early as possible
  • Make sure that your source code is consistent, and integrates
  • How? Have as much testing as you can
  • Push all code to your source code repository
  • Automatically triggers a pull/run all tests
  • Ideally: report to team and to individual developer
• Objective 2: Make sure users can start playing with new product asap
  • Once integration works, push it out to a server
  • Often there’s a test or staging server
  • Historically: Release every year, 6 months, month, week. Now: Serious standard is release multiple times a day!
  • Automatic and continuous deployment

Practices of Continuous Integration

(Credit: Martin Fowler)

1. Maintain a single source code repository: Decide on your branching strategy and make sure all developers understand it. There are different philosophies.
2. Automate the “build”: Whatever the process is for your product to turn hundreds of source code files into a working application should be fully automated so it can be triggered by any developer with a click of the button.
3. Implement a comprehensive test suite As much of the functionality as possible should be covered by tests, both functional and regression tests. Unit and integration tests. A software product approaching version 1.0 will have multiple hundreds of tests.
4. Everyone commits to the repository at least daily: Letting one developer’s local code diverge from what’s visible to the rest of the team can easily lead to bugs, lost work, replicated work.
5. Every commit should run tests: Automatically. Given that both those operations can be done with “a single click”, automatically triggering them as a result of a commit is not hard.
6. Fix broken builds immediately: When the test suite fails, ideally, the “responsible” developer should be immediately notified. Make it a group norm that you either fix the breaking commit or roll it back. The build should not be broken for any length of time.
7. Deploy to a test server: Before deploying to the live production server, do an automatic deployment to a test or staging server. Run tests there. Give access to that server to trusted testers to play with it.

Thank you. Questions?  (random Image from picsum.photos)