3 ms·

> 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 inb

> 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).

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).