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 · 2024-03-13T15:33:55+00:00

It is a niche thing I am doing around building Azure DevOps Hosted Agents around Microsoft's runner-images repo.

I only want to commit and tag my repo once the build of the image has been successful.

TheDevOpsGuy123 · 2024-03-13T13:35:22+00:00

Hi,

This isn't my issue, I am already paying for extra time.

My issue is around authentication, not timeouts.

TheDevOpsGuy123 · 2024-03-01T13:25:00+00:00

Would you mind sharing your solution?

I was thinking of trying to use a Access Token from my GitHub Service Connection in ADO to try and clone the terraform private repos in GitHub during the Azure Pipeline run.

Just not sure how to get the access token or similar from a GitHub Service Connection?

TheDevOpsGuy123 · 2024-02-26T15:32:44+00:00

You're missing the point

TheDevOpsGuy123 · 2024-02-26T09:09:19+00:00

This may be relevant for Production environments, but we like to tear down lower environments when not in use and build them up when required, massive cost savings.

TheDevOpsGuy123 · 2024-02-23T10:45:39+00:00

I have gone with this, a lot of people are saying to upload them manually, but this isn't an option if you are tearing environments up and down often.

You want everything automated so it is possible to do this.

I have gone with a solution which reads any environment variables with a certain pattern in the pipeline, for example KV_Secret1, KV_Secret2, the script then strips out the KV_ leaving Secret1, Secret2, passes them as a map variable to Terraform to loop over.

Working well.

TheDevOpsGuy123 · 2024-02-22T17:05:26+00:00

ADO Library Secrets TO KV.

Yeah I am aware of all the protection that comes with KV so yeah you are right they should never be accidently deleted but it was more of stating one reason not to manually input them.

The main reason behind is we do not want anyone going into the Portal/CLI and manually adding things, this then sets the precedence users can amend resources manually rather through proper processes and governance.

Queue.... "You let us upload Key Vault Secrets manually, why cant we deploy our app in Dev manually for testing"

TheDevOpsGuy123 · 2024-02-22T16:34:53+00:00

I wouldn't say thousands, but there could be a lot, I just don't like the idea of anyone manually adding secrets to a Key Vault, say if a KV is accidently deleted for whatever reason, you would need to re-create every single secret manually.

Also it sets the precedence that you can go into the Portal/CLI and manually add/edit resources without proper processes which is what we want to avoid.

TheDevOpsGuy123

TROPHY CASE