Blog Learn Features Forum Docs Start Building

Anvil Community Forum

[Beta] Make it difficult (or impossible) to mess up the master branch

Feature Requests
#1

I set the Editing branch to dev, do some editing, feel good about it and click on Merge changes into master. At this point I have two problems:

  1. The Editing branch is set to master. I think the Editing branch should remain dev, because it’s more likely that I want to keep editing the dev rather than the master branch
  2. I can edit the master branch and make a mess on the published version. I think the master branch should be read-only, it shouldn’t be editable not even after setting the Editing branch to master

Traditional git workflows may limit the life of a branch to a short development period, and the branch may be deleted right after the merge, but in most simple Anvil apps there will be one long lasting dev branch.

I think that the default behavior should be for the IDE to keep editing the dev branch. Automatically switching to master (or any merged branch) could be an option set while defining the environments or creating the branches or in the Look & feel.

I think that editing the branch that is served to a public URL should be absolutely impossible. At least absolutely by default impossible. I would like to see a Make branch read-only when creating a branch or when defining an environment.

5 Likes
#2

In other words, the only way to update the Published version is via Merge, not by direct editing?

#3

Yes.

And if an app has more than one published versions, I would like to set all the published branches as read-only.

I would make all the branches read-only. The user must explicitly specify which branches are read-and-write. You can publish a read-and-write branch if you want, but you need to explicitly set it that way.

As is, it’s too easy to edit everything.

Most standard workflows, even advanced ones, will only edit some development branch(es) and merge to the published one(s). I can’t see a workflow that needs to edit a published branch, it’s too dangerous. But if you really want to do that, you can edit the environment and set that branch to read-and-write.

A new app could be automatically configured out of the box with a dev read-and-write branch and a master read-only branch. The UI could have the Publish button that merges dev to master, and the simple workflow is set.

For advanced workflows, you could setup all the branches you want and tag them as read-only or not.

2 Likes
#4

Yes. Sometimes you need footguns. But it’s best if they start out with their safeties ON.

3 Likes
#5

After thinking a little about it I would change the subject from Making it difficult to mess up the master branch to Get rid of the master branch.

Here is how I would manage the app versioning:

  • A newly created app has one dev read-and-write branch and one pub read-only branch, each with its own environment
  • The Version History UI allows to create new branches and set them read-only or read-and-write
  • The Publish dialog allows to define more environments and link them to their branches
  • In the Publish dialog (or somewhere else in the app settings) there is an Only merge to read-only branches checkbox, which is checked by default
  • The Editing branch drop down does not show read-only branches
  • If there is only one read-only branch, then the Merge button will merge to that branch
  • If there are more read-only branches, then the Merge button will ask which branch to merge to

This setup will allow both one-click publishing for beginners and fancy setups for experts:

  • If you are a beginner, you edit your app and click on Merge when you are ready. If you want to revert to an older version, you can right click on a commit and click Move the "pub" branch here
  • If you are an expert, you can uncheck the Only merge to read-only branches, setup all your branches to be read-and-write and enjoy all the flexibility you want. You can even create a new branch and call it master!!
1 Like
Multiple Domains
#6

It’s only 9am and I have already worked on an app where master is the development branch and one where master is the published one.

I can understand what’s what by looking at the other branches that may be called published, dev or anything else meaningful, certainly not looking at the one named master.

1 Like
#7

Every time you merge to master, it automatically switches to master.

I think this is very very very dangerous and it should change. By “this” I mean both the fact that master is automatically checked out after the merge and the fact that master is editable.

I got hurt with it already many times. I am getting used to immediately switch back to dev, but this is far from both user and beginner friendly. Not only this is dangerous, it is also useless.

1 Like
#8

About editing the master branch, I don’t think it should be read-only. I think the git flow of commits is now available and I’m loving it. New features should use specific topic branches, but hotfixes can be made directly to master for simplicity and to quickly make the fix available in production.

Make some branches always read-only or read-only by default would be a limitation that would not be in the best interest of all. I just think that the should test some different approaches to how the editor knows when to change branches and things like that.

[Beta] Unexpected branch change when adding data table
#9

I agree,

I have enjoyed and documented it myself.

But:

  • If you are an expert, all you need to do is create a new branch, apply the hotfix, merge, delete the branch. The 3 create-merge-delete steps take just a few seconds and make the process safer
  • If you a beginner, you need to learn to keep your eyes open and make sure you don’t edit prod (now called master), which is more difficult compared to the old cleaner behavior, where it was impossible to edit prod (earlier called published)
  • Whether you are a beginner or an expert, working in an environment that exposes an app to direct editing that very likely causes it to break, is just looking for trouble. When the only advantage is avoiding those 3 quick steps

I think the use Anvil makes of git is genius and very powerful.

Unfortunately Anvil wants you to use git the way git is usually used, with the whole workflow turning around a branch called master. But I don’t see any other reason to call that branch master other than that’s what the other guys do outside of Anvil.

We do have years of testing with a read-only branch called published.
I haven’t seen any complains about it.
I have never accidentally modified it and I have never accidentally broken an app. Because it was read-only.

I don’t understand the decision to rename the published branch from a meaningful published to a confusing master.
I don’t understand the decision to make the read-only branch read-and-write.
I consider these two regressions from the old editor.

One week with the published branch read-and-write and I have had 6-7 accidents of broken apps, and we start seeing questions in the forum like this one. If the published branch was read-only this question wouldn’t exist.

I love the complete redesign and the added features, but I don’t see why the two things that were working beautifully have been changed:

  • There was a branch linked to the published app called published
  • That published branch was read-only
1 Like
Anvil's master branch [continued]
#10

I have to agree with @stefano.menci, here. The IDE should, initially, by default, turn off anything that makes it ridiculously easy to break Production. Keep the footgun – sometimes it’s needed – but start with all of its safeties turned ON.

Folks who prefer to operate with their own safeties off, should be able to turn them off, and keep them off.

From what I read here on the forum, I get the feeling that several safeties are off, by default; and even when turned on, some of them revert without warning. (Topic title names one case in point.)

For now, I’m sticking with the old IDE. It’s more work than using the new IDE. But it’s also insurance. Detecting and recovering from a broken Production can be rather costly; especially for the end-users, who may not have workarounds in place.

1 Like
#11

I’ve been using branches more in the Beta IDE, and I have to agree 100% with how annoying this is. I never want to edit the master branch immediately after merging the dev branch into it. I always want to stay in the dev branch. Having the default be that the master branch becomes current is way too dangerous.

3 Likes
#12

+1. This is super risky, especially with multiple developers - way to easy to log in at the beginning of the day, make accidental changes to master, and have these end up in production! So long as ‘master’ is the default branch you merge into (and presumably eventually push to production), some safeties as @p.colbert puts it seem like a really good idea.

In an ideal world, we would be able to use GitHub to protect branches and require review etc. In other words, use GitHub - not Anvil - as the VCS (on opt-in basis).