There's nothing like binary and asm for learning to understand how a microprocessor works.

I wish I had learned assembly. I did learn basic logic chips - which is a level or two lower - and am really glad I did. It's all just AND/OR/NOR/NOT under the covers.

All the old timers who learned assembly in school and tell us not to bother just want to keep the secrets of the priesthood hidden from us.

Why is this so bad? We actually use to follow the branching model you proposed, but around a year ago, a bunch of people who make a lot more money than me decided to switch it to 'stair case' branch model.

We would like to release faster, but there are other bottlenecks that slow down the progress (test verification is the big one, deployment to all our online prod environment is also not very fast, plus we need to roll out our releases slowly to limit risk - update a few customers on day 1, let is soak, update a few more, let it soak, update North America, let is soak, update rest of world - this way we can abort or fix the update if there is an issue before too many customers are impacted).

P.S. No one addressed the actual question I asked All these branch model requires merges between two branches. I am looking for a way to automate this process so branch A can be merged into branch B every time I run this automation. If there is a merge conflict, we would need dev manual review, but most cases, I expect to be able to merge without conflict.

I think I can do this with a powershell script (perform the merge). Once I have that working, I can figure out how to automatically run the powershell script on demand. I am thinking I can attach the script to a git 'commit' hook, and have it trigger every time a change is pushed.

In the approach I mentioned there is never an automatic merge. Only purposeful merges that a human instantiates. And code always follows the same path so there's never a release that risks removing already released code. So I don't really have this problem.

The whole idea of automatically merging seems like a bad smell to me.

If this is the process you're stuck with, I don't really have anything useful to say except that git hooks seem wrong and messy. Not sure how they would work if your commit would apply cleanly to the branch you're working with but not to the other branch. It would also probably require some pretty crazy tricks to make it work.

Isn't "git merge" or "git rebase" the script? Either it works, or there are conflicts that require a human. Needing to do this on most commits seems like a huge waste of time, but maybe the way you're working means that conflicts would be rare.

I think he wants to do the merge automatically on a regular basis. So that would need to be scripted and ideally connected to something that notified previous committers when there was a conflict.

My guess is that conflicts are relatively common. Because a lot of bugs will end up being fixed at different times. There's no typical path that all changes follow. And once that happens you're going to have a lot more conflicts.

The other problem with a commit hook type thing is that you might end up with all of your developers doing the same annoying merges. Every time someone commits a conflict to master all of your developers working on 'update_1' would have to resolve that conflict on their next local commit.

Honestly, the answer here really is to update your branching strategy. Even though I know that's not what you want to hear.

I'm the opposite. I'm an old timer who learned microcode, assembly and C in school and think it would benefit most developers to have that exposure under their belts. On more than one occasion, it helped me identify compiler bugs that were messing up my code.

Either you're missing something or I am. You should not have to manually merge fixes from master into your dev branch unless by "manual" you really mean
git merge origin/master
(which is the right thing to do)

I assumed you were literally cherrypicking commits or even worse, using some kind of tool like Beyond Compare to selectively move lines of code from one branch to another. If you are doing this, stop immediately, it is madness.

If you're using "git merge origin/master" then you don't really need to automate it. Technically, you never need to do it, since the changes will still be in master next time you merge your dev branch into master, but really you should probably do it sooner so you can find problems that are caused by the hotfixes.

Having a lot of fun beating my head against the wall with angular universal. I don't think we're really using it right. Nor is any documentation I can find helpful at all. Anyone have any experience? I have a couple questions:

What does ngApp(req, res) do on the node side? I can't find any API documentation on this - just the basic hello world examples. The angular docs don't feel the need to document this function for some reason. https://universal.angular.io/api/

How do I pass variables to the base angular template? I see res.render('index', someObj) - which normally means any property I put into someObj should be available as a local variable to the template. But that is not working.

Any idea how I would get data from node resident memory into the angular universal-cache? This is ultimately what I'm trying to do. I have a list of CMS messages that node grabs from a back end service periodically. When the browser hits our single page app for the first time - I want to pass back this object in some way that it's available to the browser for all subsequent navigation within the SPA.

Also really wondering why webpack has to re-build and optimize everything every time I restart node - even if no code changed. That seems very sub-optimal.

ftfy

Hire a team to keep everything in sync and maintain product quality. Seems like a lot of devs are working in parallel. Yes product releases at MSFT are a substantial undertaking.

I vote no to this in almost all cases. And if you're an exception to this case I doubt you'd be asking your question here.

Teams are so cheap and easy to find too...

I can create anything in node in a few minutes. It rocks for server-side.

I had assumed "hire a team" was a joke, i.e. if your dev process is so ****ed that you need to hire a team to support your team, you need to step back and re-evaluate.

We have over 1000 devs working on these branches. Keeping them in sync is no small task regardless of which process you follow. Hence looking to optimize our process if possible.

The root cause of a lot of our issues is we need to cherry-pick specific commits to multiple branches a lot. For example, some bug will be blocking our testing, or a customer will report a critical issue in production and cannot wait for the next update, or we find some security bug we need to patch all release branches with, so we need to cherry-pick that specific change into our release branch and ship that one commit to production.

Cherry-pick creates an unique commit ID in the new branch, so running 'git merge' at a later point between the two branches creates a lot of merge conflicts as GIT does not realize that one commit has already been integrated.

Basically, we are running into this issue:
https://blog.founddrama.net/2013/07/git-cherry-pick/

Yep pretty much what I figured.


How are you tracking your defects, with TFS?

We use to use TFS. We have recently migrated to VSTS which is the online version of TFS (TFS is on-prem only).

VSTS provides some nice integrations such as being able to link a pull request with a Work Item, and then the associated commits/PR link show up on the WorkItem if anyone is ever looking at it.

Yes that should help but I guess the devs are pretty much focused on their individual assignments. Perhaps not that many are interested in what they may be breaking when they make a change especially when a lot of changes are going on in parallel.

I agree with the root problem, and you need to move to a process that avoids cherry picking commits. Something like the first method I mentioned.

That being said, I don't imagine it's easy to change the culture process in an organization like you have. So... good times.

Lol a few weeks after asking me "What is a microservice?" my boss is now trying to find anything we're part of that he can call a microservice. Apparently upper management has a gigantic hard on for microservices right now.

The funny thing is I've been telling my boss for the better part of a year that we're never going to get microservices when we can't even get root access to our dev boxes. Much less some kind of shared hosting platform so each individual dev team doesn't have to cajole their Operations teams to become DevOps experts. He just ignores me.

We got funding to architect it, so who cares if it ever actually works? That's on the implementation teams. Our group always wants to make it a technical problem and ignore the cultural/bureaucratic problem. He didn't even notice that microservices was the POC that got funded. It's all just words and columns on a spreadsheet to him.

Corporations man.

I sent them these links:

https://martinfowler.com/bliki/Micro...equisites.html

https://news.ycombinator.com/item?id=12508655

https://www.stavros.io/posts/microservices-cargo-cult/

We definitely are not tall enough to do microservices and I'm pessimistic we ever will be. In our group anyway. Another part of the company is doing some really cool stuff that I am a part of. So I'm happy. Also AWS could be a magic bullet for some of those issues - as long as the app doesn't involve PCI data.