Goals

• Practice integration via GitHub pull request (PR)
• Use a CI server (Travis CI) to test a PR before integration
• Deploy an application to a PaaS (Heroku)

Today you will add a feature to the color picker to enable the user to enter the color component by number. As part of that process we will practice testing, CI and automated deployment. Check out a deployed version of the final result.

Prerequisites

1. Visit the Practical 5 page on Replit (or click the 'Start Project' link for Practical 5 on our team page).

2. Click through to the GitHub classroom assignment to create your private repository.

3. Return to the assignment on Replit and go to the Version Control panel.

4. Click the button to create a new git repository (not the one for connecting to an existing repo).

5. Open the shell and follow the instructions on your GitHub repository for connecting an existing repository:

   1. git remote add origin repo-name where repo-name is the name of your repository (e.g., https://github.com/csci312-s21/practical05-ChristopherPAndrews.git)
   2. git branch -m main
   3. git push -u origin main

6. Travis CI should start testing your application automatically (it detects the .travis.yml file). When getting started, you should have signed up for a Travis CI account using your GitHub account.

You may need to tell Travis where to find your repository. Log into Travis CI. If you don't see your repository, click on your name in the upper right hand corner and then "Settings" in the menu. Click the "Sync account" button in the upper left. Click on the csci312-f21 organization. Then, if you still can't see the repository, use the search bar (try the search term "practical05"). Click on the repo name to bring up the dashboard for your project. Keep this in a browser tab for later reference.

Deploy with Heroku

We are going to deploy our application to Heroku. Technically, we could just host our projects on Replit, but I want you to have the experience of deploying, rather than just letting the world access your dev server.

Setting up GitHub for deployment

We are going to set Heroku up so that it will automatically deploy based on GitHub commits. Since this is our "production" environment, we don't want to just deploy every piece of code, so we are going to make a special deployment branch. Any changes we make to that branch will be deployed.

Create the new branch with git checkout -b deployment. This will create the new branch and switch you to it (any uncommitted changes will come along with you).

Tell GitHub about the new branch with git push -u origin deployment.

Create the app on Heroku

When getting started, you should have signed up for a Heroku account.

Log into Heroku now.

Create a new application by clicking the "New" button in the upper right of the dashboard.

Call your new application practical05-username, where username is your GitHub username (e.g., practical05-ChristopherPAndrews).

Click the "Create App" button.

For the deployment method, chose GitHub (you may need to authenticate with GitHub at this point). In the new panel that appears, look for the setting for Automatic Deployment. Use the search tool to find the repository associated with your practical and set the branch to be deployment.

If you click on the 'Activity' tab on the top, you should see it building. Behind the scenes, Heroku is running the npm build script.

The running is controlled with the Procfile you will find in the project. It tells Heroku which script to run once the project is build. We are just defaulting to npm start. If you lok, you will see that I updated the start script to be next start -p $PORT. This tells next to look at the runtime environment variables to get the port number, rather than using the default 3000. This is essential since Heroku wants to control which port your app uses.

Once the build is complete, click the "Open app" button to view your application.

If it is all working, add a link to the new site into the README file.

Enhancing the color picker with controllable number

Now it is time to make our big change the the ColorPicker. Before you make any changes, create a feature branch named "editable-number" to isolate your modifications from the main branch:

git checkout -b editable-number

If you click the "Run" button to start the dev server, you should see the familiar ColorPicker appear in the web view. You can also run the tests with npm test, but they should fail.

You are now ready to make the changes to the LabeledSlider. The change is very simple, you are going to remove the current span which reports the value (<span>{value}</span>) and replace it with a spinner.

The spinner is actually an input element with the type "number". You can just copy the input tag from the slider and paste it where the span is. Then change the type from "range" to "number".

That's it -- you should now see spinners on the end of the sliders, and the tess should all pass.

Once the tests pass, you are ready to integrate and ultimately deploy your changes.

Integration with Travis CI

Add and then commit your changes to the editable-number branch, e.g. git commit -a -m "Transition span to numeric input". Push those changes GitHub on the editable-number branch.

git push origin editable-number

Open your repository at GitHub and create a pull request (PR) to merge the changes from your newly pushed editable-number branch onto the main branch. There will probably be a banner on the top of the main page on GitHub asking if you want to create a pull create. Alternatively, you can create the PR from the "Pull request" tab.

The next page will show you the change and ask for a brief comment. Write a short comment and click the "Create pull request" button.

This will bring you to a new page which is the page for active pull requests. Here you should see the notifications from Travis CI. It will also say if the PR can be merged into main cleanly (if not, then you will want to close the pull request and merge main into your branch so you can fix any merge issues before merging to main).

Make sure all checks have passed before merging the changes into the main branch (note that it may take a few minutes for the Travis checks to complete, especially with the entire class creating PRs at the same time).

Once all checks are green, click the "Merge pull request" button (normally, you will need to wait for the rest of the development team to give you the all clear, of course).

After the branch has been merged, a new notice will pop up asking if you would like to delete the branch. Go ahead and delete the branch.

Clean up your local repository after the merge. Return to the main branch on Replit, pull the changes from GitHub, pruning to delete remote tracking references. Then delete your local branch. To avoid mistakes when deleting branches, you can add the --dry-run option to the --prune option, e.g. git pull --prune --dry-run to double check before actually pruning anything (note this doesn't do anything, it will just report what would happen -- you still need to run the command without the --dry-run option). The command sequence is:

git checkout main
git pull --prune
git branch -d editable-number

Redeploy

Now that the main branch has been updated to reflect the changes, you can redeploy.

Switch to your deployment branch, merge main into it and then push the result up to GitHub.

git checkout deployment
git merge main
git push
git checkout main

Visit your Heroku dashboard and look at the activity. You should see it rebuilding your application. When it is done, you can open the application and see the result.

You have now successfully completed an integration and deployment cycle!

Branches

You will note that we created three different branches for a very simple change. This is to get you in practice for when you are working on the project. It is good practice to create feature branches for all of the things that you do, leaving main clean and ready to deploy. In many situations, I would say that it made sense to just deploy main automatically. However, past experience has demonstrated that the merging process can get messy. So, I think, by and large, you will be better off having a dedicated deployment branch to give you more control over when the application gets deployed while still retaining the ability to do it quickly and easily from the command line without having to go the Heroku dashboard to press buttons.

That said, be careful. Notice that I included an extra git checkout main at the end of the deployment. Try to remember to do that or you will end up inadvertently adding code to the deployment branch, which would be unwise.

Finishing Up

Your GitHub repository should already be "up-to-date" as a result of the pull request. If you have made any subsequent changes, push your completed practical to GitHub via git push --all origin. Then submit your repository to Gradescope as described here.