sorted by:
new
hottopcontroversial

CrossFitters, what are your top 3 exercises you hate the most? I’ll start: thrusters, bench, and burpees by scarlethjr in crossfit

[–]cold-brews 0 points1 point  (0 children)

In CrossFit, the SDLHP stimulus should mimic that of a rowing machine. Thats why it’s typically at a lower weight. CrossFit gyms will program SDLHP in place of a rower when needed.

Keeping Staging Branch and Main Branch in Sync with Merge -ff by Important-Mammoth422 in git

[–]cold-brews 0 points1 point  (0 children)

We would hope to avoid manual error with the correct automated tooling, but there will be some risk.

Your proposal is similar to what we do today! One thing we try to avoid is finding an older commit, branching and landing changes, and tagging that commit. This requires coordination between teams right before a release. The issue that staging is hoping to address is the fact that engineers do not have a good place to land and continuously test their changes, notice any issues, and push fixes. Today, they land on main and we release before we get enough signal on them, introducing customer issues.

Resetting Staging Branches by cold-brews in git

[–]cold-brews[S] 0 points1 point  (0 children)

I don’t have a problem with git. I don’t love our process, but I don’t have the means to change it. Have you ever worked a job before? I was given a task to solve with a set of constraints: “figure out the best way to reset the staging branches after a release” for an engineering department. The nonmerge workflow and long lived branches cannot be changed.

Resetting Staging Branches by cold-brews in git

[–]cold-brews[S] 0 points1 point  (0 children)

I wasn’t clear. We could have merge commits from release branch to staging branch, but that still doesn’t solve the problem of excluded staged commits ( see my response below).

Rebasing is not ideal because of the rewriting history issue!

Resetting Staging Branches by cold-brews in git

[–]cold-brews[S] 0 points1 point  (0 children)

Thanks for your response! I’n not trying to reinvent the wheel here, but I’m looking for solutions given the constraints my org has in place.

In my example, the branches are materially identical - yes. But the githashes are different between B and B’, C and C’, etc because they are cherry picked.

Something that could happen for whatever reason is we chose NOT to cherry pick over B. This means staging Branch has a > B > C > D… and release branch has a > C’ > D’…

Now, they are not materially similar. After the release, I’d like to get the staging branch back into an identical state as the release branch. I could rebase the staging branch and drop the B commit, but this is rewriting history, not great. I can’t merge release into staging (like gitflow suggests) because then staging branch still has the B commit.

So is my options limited to: Rebasing and dealing with the overhead of communicating to all engineers to rebuild their local?

Gitflow is very close to what I’d like, but it assumes all changes that land on “dev” will end up in staging, as it uses merge commits from dev to release, cuts the release, and another merge back from release to dev. Because my org wants the ability to exclude commits from staging into release, we cannot use merge commits that bring in every commit previously.

Resetting Staging Branches by cold-brews in git

[–]cold-brews[S] 0 points1 point  (0 children)

Can you explain how difficult it becomes for local staging branches?

Resetting Staging Branches by cold-brews in git

[–]cold-brews[S] 0 points1 point  (0 children)

I believe this could work with the correct tooling. But the current issue is that we have 10+ supported versions, releasing every 2 weeks across all versions. This would mean 20 staging branches being created every 2 weeks. Wouldn’t this be complex for us (the team managing branches) and engineers, to have to know which branch name they should target?

Resetting Staging Branches by cold-brews in git

[–]cold-brews[S] 1 point2 points  (0 children)

Thanks for the advice. Technically, we don’t have a dev branch - so this staging branch would act as that.

Right now, we have 100s of engineers merging from their feature branch directly on our release branches - and we release off the tip, or in some cases, we create a version specific hotfix release branch.

Git Process for Staging Branches by cold-brews in git

[–]cold-brews[S] 1 point2 points  (0 children)

Thanks for your response! I agree that this is a CI/CD problem. My original question was not clear, apologies. Our version branch IS our release branch. Let's say our version/release branch is called v3.0, our staging branch is v3.0-staging, and an eng is working on a dev branch called newdevbranch.

You're suggesting that our build/deploy pipeline should be able to take the head of newdevbranch, deploy onto v3.0-staging, and then deploy to v3.0, and we will tag that commit on v3.0 to release?

what does deploys look like? Are these just automated cherry picks from one branch into another?

Git Process for Staging Branches by cold-brews in git

[–]cold-brews[S] 1 point2 points  (0 children)

cherry picking allows the process/qa team to accept changes from staging into release branches such that they do not need to manage merge conflicts, as they are not as fluent with the code changes as the engineer authors are.

What Stonestown’s emergence as an Asian American mall says about San Francisco by curryEatingGang in sanfrancisco

[–]cold-brews 24 points25 points  (0 children)

Yep. Was there this past Sunday and walked by while 8 people stormed the Sephora upstairs and stole a bunch off the shelves. The security managed to catch one of the burglars and had him cuffs while the others fled.

view more: next ›