Nodejs.dev: Default branch

[alexandrtovmach]

Summary

We have strange situation with two active branches:

• master
• staging

Of course, it seems like a right way of development, but I can't find any environment separation. So we need to decide how we're moving forward:

1. Set up and support two environmets. Make staging as default branch, to get dependabot updates to it. Make master branch like production, to allow only merge from staging + hotfixes
2. Merge staging to master, and deprecate first one.

My vote for second option

[alexandrtovmach]

@nodejs/website-redesign
@nodejs/nodejs-dev

[alexandrtovmach]

Any suggestions?

[alexandrtovmach]

Today I found #318, with details about suggested approach. I'm fully okay with that, but let's just make staging as a default branch to prevent conflicts in a future

[benhalverson]

I agree with making staging as the new default

[alexandrtovmach]

Do we have configured builds for:

• master -> https://nodejs.dev
• staging -> some link

I can't find any details about it and related code.

[styfle]

Hello Alexandr and team 👋

You might find it easier to host nodejs.dev on Vercel because you can configure different domains per branch. https://vercel.com/blog/branch-domains

I confirmed that Vercel can build and deploy this repo as-is by visiting the https://vercel.com/import page.

See the result here: https://nodejs-dev-1ui81t97n.now.sh

[alexandrtovmach]

@styfle Thanks for the info and investigation, but as much as I know we're going to use netlify as hosting

[benhalverson]

Currently the staging build is at whatever the latest sha is at.
For example
https://storage.googleapis.com/staging.nodejs.dev/224fb7c/index.html
I found that 224... number from this https://github.com/nodejs/nodejs.dev/pull/491/commits

[alexandrtovmach]

@benhalverson But we haven't permanent link for staging, right? So it's sounds like not completed environment. Do you know who is the owner of nodejs.dev domain?

[benhalverson]

That is correct. A permanent link like staging.nodejs.dev does not exist right now.
I think @bnb or @MylesBorins would know who the owner for nodejs.dev is.

[MylesBorins]

So for right now I am -1 with making staging the default. Staging, to the best of my understanding, is the branch where work is being done on the broader re-design... work that has primarily been stalled for months. The majority of PRs that I'm aware of that come to this repo (and I confirmed this with the most recently 5 or so PRs) are targeting master and have nothing to do with the redesign.

It seems to me like we have conflicting issues here.

1. A desire for a staging and master to make rolling out to prod "safer"
2. Two working branches where work is being done

I'm honestly not in favor of making changes to either of these at the moment.

For 1) we don't use a staging vs. master approach for nodejs.org and I don't see a ton of advantage in keeping a staging site and rolling out "planned updates" at any sort of cadence. While it is a pain if the site breaks, it really isn't the end of the world. I don't see any advantage to setting up a more complicated workflow for rolling out to "production". Please feel free to debate me here... I understand this isn't necessarily "best practices" but I think we also need to be conscious of the resources to maintain a more complicated workflow.

for 2) I'm not convinced that "staging" is where the majority of work is actually being done, and creating a process where folks need to target staging then have their changes backported to master seems like asking a ton of additional work both for the folks contributing the change (wait why does this look so different then the site on nodejs.dev) and the folks maintaining it (wait now I have to backport things). It seems far more reasonable that the individuals working on staging create a workflow that enables them to keep staging up to date.

With keeping staging up to date against master we can setup automation to handle rebasing, there will likely be conflicts, but it is good to find those sooner rather than later when a branch has been being worked on for so long.

I recognize in all of this that I have not been as active in this repo for a while, so if I'm totally off please let me know, point me to some discussion, and I'll get myself up to date to make a more informed decision.

FWIW I current own the domain, although I should at some point transfer it to the foundation (before I have to pay to renew it 😅). One thing to keep in mind is that .dev domains utilize HSTS so it requires HTTPS to work. I can get staging.nodejs.dev working with the current setup if folks want... just have to throw cloudflare in front.

[alexandrtovmach]

@MylesBorins As I said in prescription, my vote for the same approach to deprecate staging and keep only one environment. I just won't be "changing man" from initial point, that's why I'm open for discussion, instead of forcing new approach.

[alexandrtovmach]

@MylesBorins Could you make staging as default branch for this repo?

[MylesBorins]

@alexandrtovmach I mentioned a number or reasons why I don't think we should make staging the default and have not seen a response that justified the change.

Staging currently is behind master and has a bunch of website redesign content that is not relevant to most folks looking to do drive by contributions. I think it would be a step backwards to change the default.

Can you help me understand how changing the default would improve things.

To be explicit I am -1 to this change

[benhalverson]

I think we should merge staging into master and be done with it. If we do this right now we would have a bunch or lorem text on the homepage. I asked for what text we should use here. #637

Right now all the feature work is being done on staging and documentation work is done against master. I agree the project was stalled, but we have a few active contributors again.

I'm not sure why the staging branch was started but #318 is when it happened.

[alexandrtovmach]

My points for making staging as default branch:

• docs updates coming to master
• dependabot updates coming to master
• random developers make contributions to master instead of staging, because they are not confident with the process
• everything above produce merge conflicts and duplicating work that did on both envs

My points for deprecating staging and keep development in master:

• avoid any merge conflicts
• we already have fixed PR preview functionality, to check how it looks before merge, so staging not need anymore
  One thing is "Lorem ipsum", but I suppose it's okay as we're still on "development" state

I'm personally just want to contribute in comfortable way, and that's why I'm forcing this issue to be resolved by any decision.

[MylesBorins]

@alexandrtovmach I think that we can set up some infrastructure to automate the process of keeping staging rebased against master. I'm currently -1 to landing it in it's current state as it is not ready for production yet. I've added some explicit review to https://github.com/nodejs/nodejs.dev/pull/654 with issues that I have found.

[alexandrtovmach]

Okay, so the final decision is:

• merge master to staging automatically with CI (#661) to keep development environment "up-to-date"
• continue redesign work in staging

I'm okay with that plan 👍

[alexandrtovmach]

Master is the main branch now, resolved here #718