scriptology / release-based-workflow

Alien Invasion

This is the sample game that is built in the first three Chapter of mobile HTML5 Game Development.

It is released under both the GPL and MIT license to do with what you will.

Playable Version: https://scriptology.github.io/release-based-workflow/

Bit.ly link for mobile: http://bit.ly/html5-invasion

If you make an interesting fork or enhancement of the game, let me know and it'll get linked to here. This original repo will stay matching the code in the book.

For more HTML5 Game Development resources, see:

• HTML5 Game Demos
• HTML5 GameDev Tutorials
• HTML5 Game Development News
• HTML5 Game Engines

release-based-workflow's Issues

Organizing a release

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.

Create a patch release

A final release

You updated the source code, but users can't readily access your most recent changes. Prepare a new release, and distribute that release to the necessary channels.

Step 14: Create release v1.0.1

With automation, you don't have to spend a lot of time working on your release draft. Follow the same steps we took before, and you'll find a new release drafted and ready for your approval.

⌨️ Activity: Complete release

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 3 releases.
2. Click the Edit button next to your draft release.
3. Practice your semantic version syntax. What should this version be labeled?
4. Click Publish release.

---

I'll respond below with your next steps.

Finalize the release

Finalizing releases

It's important to be aware of the information what will be visible in that release. In the pre-release, the version and commit messages are visible.

Semantic versioning

Semantic versioning is a formal convention for specifying compatibility. It uses a three-part version number: major version; minor version; and patch. Version numbers convey meaning about the underlying code and what has been modified. For example, versioning could be handled as follows:

Code status	Stage	Rule	Example version
First release	New product	Start with 1.0.0	1.0.0
Backward compatible fix	Patch release	Increment the third digit	1.0.1
Backward compatible new feature	Minor release	Increment the middle digit and reset the last digit to zero	1.1.0
Breaking updates	Major release	Increment the first digit and reset the middle and last digits to zero	2.0.0

Check out this article on Semantic versioning to learn more.

Step 11: Finalize the release

Let's now change our recently automated release from draft to latest release.

⌨️ Activity: Finalize release

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 1 release.
2. Click the Edit button next to your draft release.
3. Using semantic versioning, then type v1.0.0 as your release title.
4. Include a description of the changes made in this branch.
5. Click Publish release.

---

I'll respond below with your next step.

Create a release pull request

Release branches and main

You should open a pull request between your release branch and main as early as possible. It might be open for a long time, and that's okay. The pull request corresponds to the work in the project board.

The pull request description should:

• Include a brief description of the pull request
• Include a task list of expected features
• Propose a ship date

To expedite the creation of this pull request, I've added a pull request template to the repository. Now when you create a pull request, default text will automatically be displayed, this should help you identify and fill out all the necessary information. If you don't want to use the template content, just remove the text from the pull request and repace it with your pull request message.

Step 6: Open a release pull request

Let's make a new pull request comparing the release branch to the main branch.

⌨️ Activity: Open a pull request

1. Open a new pull request with base: main and compare: release-v1.0.
2. Ensure the title of your pull request is Release v1.0
3. Include a detailed pull request body.

---

I'll respond in your new pull request with next steps.

Adding a feature

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.

Congratulations

Well done!

Congratulations @scriptology, you've completed the Creating a Release Based workflow course!

During this course you successfully:

• Created a release on GitHub based on a Git tag
• Built an automated project board within your repository to manage your release
  • If you look at the board now, everything has moved to the Done column
• Created and committed changes on a release branch
• Created a hot fix branch to fix a bug on the release branch
• Installed a Probot app to craft a changelog for your releases

Keep learning

Want to keep learning? Feel free to check out our other courses!

---

I won't respond to this issue, go ahead and close it when finished!

Welcome

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.