The Short Notes On Branches
A Simplified Work Flow
Your existing codebase has a master branch in production. Your develop branch is aligned and ready for new work.
You start a new feature or patch. You create a feature branch usually named feature/super-cool-new-thing. When you’ve completed the code and it looks stable you finish the feature. GitFlow will merge this with your local develop. No conflicts or other issues? Push it. The rest of your dev team has a new reference point for your upcoming release.
Start a release when you are done coming up with super cool new features. When you start a release GitFlow will create a new branch named release/<version>. If you’ve had prior release branches and tags GitFlow will see this and bump the next minor or point release. If not you’ll need to name your first release. Convention is to use the major.minor.point-release version format.
Put the release into production after testing. When you finish a release, GitFlow will merge this with master, tag the commit with the version of that release, and make sure the develop branch is updated with any code changes that may have happened during testing/production.
Seems simple, but I quickly found a corner case that did not seem to be addressed. What do you do when your release branch testing uncovers a bug?
My patch Branch
One of the complaints about GitFlow is what do you do when your code is ready for testing and find a bug. The branch model does not clearly define the methodology and in this vacuum a lot of people have shared their opinions and many have tried to fill that void. There were no methodologies that I came across that I really liked, so I created my own (which I’m sure someone else has done already).
After I start a new release branch I run through a series of tests. Sometimes the tests fail and I need to update the code. What do you do now? Start a new feature branch? It is not really a feature. It also makes it very hard to see what “feature” is needed to get the release into production versus a feature you (or some other developer) has started for a different future release. The bigger the team the more problematic this becomes.
In order to increase visibility for the team lead that is managing the repository I introduced the “patch” branch. Patch branches in my branch model are specifically for code changes to be rolled directly to the release (and back to develop) branches. It is the equivalent of a hotfix that goes on release instead of master.
While this is not a standard GitFlow model and thus I don’t have a one-button-click way to start and finish a patch release in SmartGit, the nomenclature “standard” keeps us all on the same page.
This is how I went about building a version of nginx that supports RTMP media streaming on an Ubuntu 16.04 VirtualBox. It is not a simple plug-and-play exercise but anyone with basic Linux system admin skills can get this going.
Not surprising. Apple already has the user base. Doesn’t help make a solid business argument when you’re losing nearly $100M per year with no profitability in sight.
The current streaming business model does not work!
Apple Music doesn’t want to buy Tidal
The biggest problem with could-centric development is the 100% loss of productivity when the network is down. While not an issue for most corporate lemmings pulling their 9-5, it is a notable issue for today’s digital nomads. While corporate techies will not go away, remote workers with flexible lifestyles and the inconsistent connectivity that goes with it will continue to grow. More tech workers will be connecting from outside the office. They may, or may not, have network access.
When you don’t have access to the network you cannot connect to your cloud service. You cannot work. With locally virtualized systems on the other hand, you have everything you need. As long as you have power or your battery life is good you can be productive. Next time you get back to civilization, meaning anywhere with a network connection, you push your work out to the world.
Cloud computing is the current way to do things in software but NOT for daily development. Unless you like having a reason to not do anything for an afternoon while your ISP restores the network or while you wait for the plane to get back on the ground.
The death of localhost and the rise of cloud development