3 ms·

Those configs feel like they're longer than a Russian literature novel. Setting them up is a pain: why do I need a different set of permissions to set up a ser

Those configs feel like they're longer than a Russian literature novel. Setting them up is a pain: why do I need a different set of permissions to set up a service connection for every single pipeline? Why does my manager who has what we can only assume is a _marginally different_ set of permissions just see an approve button for the service connection but I get taken to page asking me to setup a service connection? (Which ultimately fails anyway) Why does it want to create a Kubernetes secret on every deploy? It does funny things with the output from Kustomise, and we discovered we had to add parameters in to make it stop adding characters to the end of the generated configs. Did you once, look at a pipeline? Be prepared to get more emails from devops than an overly-eager marketing department. If you have a Terraform in your Pipeline, Azure will lie to you about the status of you Apply's: it'll tell the pipeline that the resource was created, when it fact it was not successfully created, this will mess up your TF state. If you deploy to a K8s cluster, and your application crashes during startup for some reason, the pipeline treats this as a failure, IMO that's beyond it's set of responsibilities: it should take care of making sure the deployment configs get to Kubernetes, application failing to start is the concern and responsibility of the developer, not the CI pipeline.

GordonS 6y ago
I can't comment on the k8s stuff specifically, but that does seem to be rather notorious for dubious documentation and features. > Those configs feel like they're longer than a Russian literature novel Assuming you mean pipelines YAML files, I can't agree - my pipelines are always quite terse, and you can also split them into multiple files if wanted. IME they are no longer than pipeline configs from AppVeyor, Travis etc. > Setting them up is a pain: why do I need a different set of permissions to set up a service connection for every single pipeline? IIRC, you don't - I'm sure there is an option when creating the connection to grant permission to all pipelines. > Why does my manager who has what we can only assume is a _marginally different_ set of permissions just see an approve button for the service connection but I get taken to page asking me to setup a service connection? (Which ultimately fails anyway) Working with service connections is definitely a PITA, but since you need to have the requisite permissions in Azure, I'm not sure there is a good way of handling things. > Did you once, look at a pipeline? Be prepared to get more emails from devops than an overly-eager marketing department. I work with pipelines all the time, and don't recall getting a single email from Azure DevOps marketing people.
- FridgeSeal 6y ago
  > I work with pipelines all the time, and don't recall getting a single email from Azure DevOps marketing people. Oh sorry I worded that poorly - I mean my inbox is absolutely crowded with emails from devops itself. I'm sure I can turn it off, it's just absurdly chatty out of the box. > Assuming you mean pipelines YAML files, I can't agree - my pipelines are always quite terse, and you can also split them into multiple files if wanted. IME they are no longer than pipeline configs from AppVeyor, Travis etc. Yeah I was, how long are yours? I've got a couple here that are bordering on 300 lines which is pretty wild considering I only need to build a container and push it to K8s... Best CI/CD I've had was with Drone: equivalent build YAMLS were probably 20-30 lines, tops > Working with service connections is definitely a PITA, but since you need to have the requisite permissions in Azure, I'm not sure there is a good way of handling things. Compared to AWS' permission model, my experience is that it's distributed amongst throughout a number of locations, and needlessly complicated to ensure that team members have the permissions they need.
  - tracker1 6y ago
    On the email chatter, have to agree... we have the ones we mostly care about in a Teams channel (PR request). I need to get another filter for "mentions you" so that I can send the rest to the trash. As to the pipeline length, most of my interactions are npm/node scripts via package.json within various projects . Often even other language projects I'll use node/npm as a task runner which makes for decent glue code. That tends to keep my pipeline files much smaller as it's usually... 1: add tools 2: configure environment injections 3. run npm script(s) At least then I have a little more control. Same for github, gitlab and others. It seems Azure and AWS permissions seem to be at opposite ends of the spectrum. I will say I find dealing with Azure's Storage services (Blob, Table, Queue) to be really nice for a lot of common use cases. At least the tables and queues.
  - GordonS 6y ago
    > Yeah I was, how long are yours? I've got a couple here that are bordering on 300 lines which is pretty wild considering I only need to build a container and push it to K8s... Best CI/CD I've had was with Drone: equivalent build YAMLS were probably 20-30 lines, tops As a random example, I have a pipeline that builds a multi-arch container image for both x64 and ARM and pushes it to ACR, and also builds, tests and deploys a Function App, and publishes artifacts. The main pipeline file is about 75 lines, and it makes use of 3 other files that setup docker buildx, login to ACR, set the build version, that kind of thing. In practice, I find these kind of "setup" tasks often use as many lines as the main file, but it's often reusable stuff, and splitting them out into templates is really helpful, I think. In total, it's around 120 lines for all the pipeline files. I am keen on makefiles though, so a lot of the actual build script is in them, ensuring we can also build locally too. Another example is a web app, where it builds, runs unit and integration tests in a container, and publishes build artifacts for a release pipeline to take over deployment. It also has a 2nd job where it builds some Windows-specific stuff in a Windows agent. Whole thing is less than 100 lines. The simplest pipelines will be less than 30 lines - for example, the web app I mentioned could easily be done in 30 lines if tests didn't run in a container. I don't mind taking a look at your YAML file if you think another pair of eyes would help (my email is in my profile, and you can anonymise bits of your file if you want).

GordonS 6y ago

I can't comment on the k8s stuff specifically, but that does seem to be rather notorious for dubious documentation and features. > Those configs feel like they're longer than a Russian literature novel Assuming you mean pipelines YAML files, I can't agree - my pipelines are always quite terse, and you can also split them into multiple files if wanted. IME they are no longer than pipeline configs from AppVeyor, Travis etc. > Setting them up is a pain: why do I need a different set of permissions to set up a service connection for every single pipeline? IIRC, you don't - I'm sure there is an option when creating the connection to grant permission to all pipelines. > Why does my manager who has what we can only assume is a _marginally different_ set of permissions just see an approve button for the service connection but I get taken to page asking me to setup a service connection? (Which ultimately fails anyway) Working with service connections is definitely a PITA, but since you need to have the requisite permissions in Azure, I'm not sure there is a good way of handling things. > Did you once, look at a pipeline? Be prepared to get more emails from devops than an overly-eager marketing department. I work with pipelines all the time, and don't recall getting a single email from Azure DevOps marketing people.

FridgeSeal 6y ago
> I work with pipelines all the time, and don't recall getting a single email from Azure DevOps marketing people. Oh sorry I worded that poorly - I mean my inbox is absolutely crowded with emails from devops itself. I'm sure I can turn it off, it's just absurdly chatty out of the box. > Assuming you mean pipelines YAML files, I can't agree - my pipelines are always quite terse, and you can also split them into multiple files if wanted. IME they are no longer than pipeline configs from AppVeyor, Travis etc. Yeah I was, how long are yours? I've got a couple here that are bordering on 300 lines which is pretty wild considering I only need to build a container and push it to K8s... Best CI/CD I've had was with Drone: equivalent build YAMLS were probably 20-30 lines, tops > Working with service connections is definitely a PITA, but since you need to have the requisite permissions in Azure, I'm not sure there is a good way of handling things. Compared to AWS' permission model, my experience is that it's distributed amongst throughout a number of locations, and needlessly complicated to ensure that team members have the permissions they need.
- tracker1 6y ago
  On the email chatter, have to agree... we have the ones we mostly care about in a Teams channel (PR request). I need to get another filter for "mentions you" so that I can send the rest to the trash. As to the pipeline length, most of my interactions are npm/node scripts via package.json within various projects . Often even other language projects I'll use node/npm as a task runner which makes for decent glue code. That tends to keep my pipeline files much smaller as it's usually... 1: add tools 2: configure environment injections 3. run npm script(s) At least then I have a little more control. Same for github, gitlab and others. It seems Azure and AWS permissions seem to be at opposite ends of the spectrum. I will say I find dealing with Azure's Storage services (Blob, Table, Queue) to be really nice for a lot of common use cases. At least the tables and queues.
- GordonS 6y ago
  > Yeah I was, how long are yours? I've got a couple here that are bordering on 300 lines which is pretty wild considering I only need to build a container and push it to K8s... Best CI/CD I've had was with Drone: equivalent build YAMLS were probably 20-30 lines, tops As a random example, I have a pipeline that builds a multi-arch container image for both x64 and ARM and pushes it to ACR, and also builds, tests and deploys a Function App, and publishes artifacts. The main pipeline file is about 75 lines, and it makes use of 3 other files that setup docker buildx, login to ACR, set the build version, that kind of thing. In practice, I find these kind of "setup" tasks often use as many lines as the main file, but it's often reusable stuff, and splitting them out into templates is really helpful, I think. In total, it's around 120 lines for all the pipeline files. I am keen on makefiles though, so a lot of the actual build script is in them, ensuring we can also build locally too. Another example is a web app, where it builds, runs unit and integration tests in a container, and publishes build artifacts for a release pipeline to take over deployment. It also has a 2nd job where it builds some Windows-specific stuff in a Windows agent. Whole thing is less than 100 lines. The simplest pipelines will be less than 30 lines - for example, the web app I mentioned could easily be done in 30 lines if tests didn't run in a container. I don't mind taking a look at your YAML file if you think another pair of eyes would help (my email is in my profile, and you can anonymise bits of your file if you want).