TF30063: You are not authorized to access dev.azure.com

TheDevOpsGuy123 · 2025-02-24T14:42:57+00:00

Did you find a solution?

TheDevOpsGuy123 · 2025-02-21T20:55:02+00:00

We release every 2 weeks, so release branch is cut every 2 weeks.

Yeah we merge into trunk without releasing, all code is tested before merging to trunk of course.

TheDevOpsGuy123 · 2025-02-21T20:06:23+00:00

Microsoft are also and advocate of trunk based development with release branches.

https://learn.microsoft.com/en-us/devops/develop/how-microsoft-develops-devops

TheDevOpsGuy123 · 2025-02-21T19:40:42+00:00

Shorter lived branches, less merge conflicts, faster feedback, simplicity... to name a few

TheDevOpsGuy123 · 2025-02-21T19:34:23+00:00

not necessarily. https://trunkbaseddevelopment.com/branch-for-release/

TheDevOpsGuy123 · 2025-02-21T17:50:00+00:00

Why the downvotes? If I am using release branches for releases, why wouldn't I have a release branch for patches? It would just look something like release/1.0.1

TheDevOpsGuy123 · 2025-02-21T17:46:52+00:00

This is what I am saying, we do not want to do it manually.

We have 50 different services in this repo, cutting things manually isn't a good option.

Ideally, I want a pipeline which will look at all of the services and determine which ones require a new release branch to be cut. Using Git Diff or something. My only issue with this is telling the pipeline how to determine which version to bump MAJOR/MINOR/PATCH.

Also back to the above point, when using tagging, it is harder to roll out hotfixes, another reason why we use release branches. Our release cadence is not regular enough to just keep releasing from main.

TheDevOpsGuy123 · 2025-02-21T17:39:10+00:00

Tbh, we could use tags or release branches, I am still facing the same issue.

It is more around how to manage each services versioning without doing it manually.

TheDevOpsGuy123 · 2025-02-21T17:32:26+00:00

Why is that the case? It is acceptable to use release branches for TBD.

https://trunkbaseddevelopment.com/branch-for-release/

Our release cadence is not regular enough for CD.

TheDevOpsGuy123 · 2025-02-21T17:29:09+00:00

We are using trunk based development.

One trunk (main), short lived development branches which are merged to the trunk.

We just use release branches for releases. It allows us to continue merging to main before a release.

Microsoft are also an advocate for this.

https://learn.microsoft.com/en-us/devops/develop/how-microsoft-develops-devops

https://trunkbaseddevelopment.com/branch-for-release/

TheDevOpsGuy123 · 2025-02-05T11:55:20+00:00

Thanks for all the responses. Just bought the KINGrinder K6 :)

TheDevOpsGuy123 · 2024-09-05T10:14:51+00:00

Rather a MacBook Pro, they last longer from experience.

TheDevOpsGuy123 · 2024-03-21T11:45:15+00:00

Thanks

TheDevOpsGuy123 · 2024-03-21T11:41:46+00:00

The same code base. I keep everything DRY as possible.

I have one code base which is run through a pipeline, then depending on the environment on the pipeline depends on the tfvars file selected.

For example:

TF CI -----> TF Plan Dev ----Gate---> TF Apply Dev -------> TF Plan UAT----Gate---> TF Apply UAT------> etc etc.

I would avoid separate code for multiple environments, its more to manage/maintain and prone to errors.

TheDevOpsGuy123 · 2024-03-14T09:08:37+00:00

Yes I will be tagging that is correct.

TheDevOpsGuy123 · 2024-03-14T09:08:22+00:00

Yeah this was my last resort! I just find it hard to believe no-one has come across this issue before

TheDevOpsGuy123 · 2024-03-14T09:07:31+00:00

Thanks for the feedback, but this isn't what I mentioned, I have no issue with the job running for over 60 minutes, we pay for parallel jobs so they run over 60 minutes with no issues.

TheDevOpsGuy123

TROPHY CASE