lockharttech / release-based-workflow Goto Github PK
View Code? Open in Web Editor NEWHome Page: https://lab.github.com/githubtraining/create-a-release-based-workflow
License: MIT License
Home Page: https://lab.github.com/githubtraining/create-a-release-based-workflow
License: MIT License
Congratulations @LockhartTech, you've completed the Creating a Release Based workflow course!
Want to keep learning? Feel free to check out our other courses!
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?
On GitHub, let's keep track of several related issues with a GitHub project board.
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.
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.
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.
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 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.
Let's now change our recently automated release from draft to latest release.
v1.0.0
as your release title.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 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 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.
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.
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.
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.
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.
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.
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.
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.
README.md
to point to your own GitHub Pages site.release-v1.0
as the base
branch, and your new branch as compare
.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:
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.
Let's make a new pull request comparing the release
branch to the main
branch.
base: main
and compare: release-v1.0
.A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.