Welcome

This repository will teach you about release workflows. By the end of this course, you'll have two versions of the classic arcade game, "Alien Invasion". Let's get started! If you'd like, you can use GitHub Pages to host your Invasion game and see live updates. Go to the Settings tab of this repository. Scroll down to GitHub Pages. Select main as a Source.

The GitHub flow

The GitHub flow is a lightweight, branch-based workflow for projects with regular deployments.

Some projects may deploy more often, with continuous deployment. There might be a "release" every time there's a new commit on main.

But, some projects rely on a different structure for versions and releases.

Versions

Versions are different iterations of updated software like operating systems, apps, or dependencies. Common examples are "Windows 8.1" to "Windows 10", or "macOS High Sierra" to "macOS Mojave".

Developers update code, and then run tests on the project for bugs. During that time, the developers might set up certain securities to protect from new code or bugs. Then, the tested code is ready for production. Teams version the code and release it for installation by end users.

Step 1: Create a beta release

Create a release for this repository on GitHub.

GitHub Releases point to a specific commit. Releases can include release notes in Markdown, and attached binaries.

Before using a release based workflow for a larger release, let's create a tag and release.

⌨️ Activity: Create a release for the current codebase

1. Go to the Releases page for this repository.
   • You can click the link above, or click the Code tab at the top of your repository. Then, find the navigation bar below the repository description, and click 0 releases.
2. Click Create a new release.
3. In the field for Tag version, specify a number. In this case, use v0.9. Keep the Target as main.
4. Give the release a title, like "First beta release". If you'd like, you could also give the release a short description.
5. Select the checkbox next to This is a pre-release, since it is representing a beta version.
6. Click Publish release.

Note: There are a lot of options here, like pre-releases, and attaching binaries. We'll talk more about these later. You might also see some yellow bars along the top in this repository for existing branches. We'll come to those later, too.

---

I'll respond below for your next step

Sometimes I respond too fast for the page to update! If you perform an expected action and don't see a response, wait a few seconds and refresh the page for your next steps.

Organizing Releases

Creating a release package on GitHub might be easy, but it's only a piece of the puzzle. Releases often involve prioritized bug fixes, feature releases, and assorted tasks. How do you make sure you're keeping track? What happens if you want to save the most exciting features for a larger update?

Step 2: Create a project board

On GitHub, let's keep track of several related issues with a GitHub project board.

⌨️ Activity: Create a project board

1. Navigate to the Projects tab of this repository.
2. Click Create a project.
3. Under Project board name, type "Release 1.0 tracker".
4. In the Template dropdown, select Automated kanban.
5. Click Create project.

Note: After you create your project, you'll see that GitHub has created a few cards for you. You can keep these, or delete them.

---

I'll respond below with your next step.

Release management

As you prepare for a future release, you'll need to organize more than the tasks and features. It's important to create a clear workflow for your team, and to make sure that the work remains organized.

There are several strategies for managing releases. Some teams might use long-lived branches, like production, dev, and main. Some teams use simple feature branches, releasing from the main branch.

No one strategy is better than another. We always recommend being intentional about branches and reducing long-lived branches whenever possible.

In this exercise, you'll use the release-v1.0 branch to be your one long-lived branch per release version.

Protected branches

Like the main branch, you can protect release branches. This means you can protect branches from force pushes or accidental deletion. This is already configured in this repository.

Add a feature

Releases are usually made of many smaller changes. This is a practice repository, but we will still make at least two feature adjustments.

Since we don't know of any bugs, we'll focus on a few features to update on our game before the version update.

• You should update the README.md to point to the correct game URL
• I'll help you change the text colors to green

Step 4: Add a new feature on the release branch

First, update the URL in your README.md.

Using the GitHub flow, make your update, and open a pull request with release-v1.0 as your base branch.

⌨️ Activity: Update the README.md

1. Create a new branch and change the URL in the README.md to point to your own GitHub Pages site.
2. Open a pull request with release-v1.0 as the base branch, and your new branch as compare.
3. Fill in the pull request template to describe your changes.
4. Add the pull request to the project board, using the Projects section on the right side of the pull request.

---

I'll respond in your pull request with the next step.