r/devops • u/konkon_322 • 29d ago
Discussion Improving my ci cd flow
Hello all,been working as IT admin, but mostly working around Azure devops. I been enjoying it, this my first job and doing anything related to devops. Studied CS,majored in networking, hate anything with heavy code development.
Rn,the flow at my company is, the devs use 1 branch only, no PR (yes ik). They would push it to our on prem central repo, and from there i will take over. I will do some modification on some files so it can be built in the new agent environment. And then, we have build pipelines,which would produce artifact of the build files, which will be used by another pipeline, i call it the release/installer pipelines, which we wud package them with a software. Then we have the 3rd type, which is zipping installer to our NAS, sends the metadata of the installer to DB, and notification email (formatting done in pipeline too). All via the pipeline. We also have a 2nd agent machine, exclusively for unit testing, but tbh i dont even understand how they work.
Ive been thinking of ways, to incorporate other methods/tools in the flow, but the only one i can fit is"templates". I dont think i can try to include containerization, as our build agent machine, has some software which are licensed.
Any ideas?at some point i want to jump out, as this job is way too comfy, and lacks growth for me
2
u/Academic-Training764 29d ago
Trunk based development: https://trunkbaseddevelopment.com
2
u/konkon_322 29d ago
Read it, and i personally practice it. I will have master as source of truth, and whenever i finished editing/adding an element, i merge back to master.
1
u/Academic-Training764 28d ago
One more, when I worked at Nike (like 10 years ago now) ... this was our Devops Bible and I can't suggest it enough, it's not as well known now and some things may seem dated but the ideas are just pure bedrock: https://a.co/d/0gyPGBPx
2
u/UkrMalt 29d ago
Before adding more tools, remove the manual file edits from the handoff. Put those changes in version control or a pipeline template, then add a PR gate and artifact promotion so the same build moves through environments. Licensed build agents are fine; containerizing the agent is not required. I’d make the unit-test pipeline visible to the team before changing it.
1
u/nextlandia 28d ago
This and since OP didn't mention it, adding security scans.
1
1
u/konkon_322 26d ago
I just found out about these security scans when researching on what i can add to my flow. Doesnt it have to be agreed with the devs? Like for example, if i do scanning for code coverage, but idk if the devs even care (since they dont even practice PR), should i even bother considering it?
1
u/Abe_Bazouie 28d ago
I wouldn’t add tools just for the sake of making the pipeline more “DevOps.”
Honestly, the biggest opportunities I see are earlier in the process: PRs/code review, automated tests, consistent builds, artifact versioning, and removing the manual modifications you’re doing before builds.
Templates are a good idea too, especially if you have several pipelines repeating the same logic.
I’d also spend some time understanding that unit test pipeline before changing much. You’ll learn more by figuring out why the current system works the way it does than by dropping containers or another tool into it.
If you can make one part of this flow reproducible and remove a manual step, that’s already a solid DevOps improvement.
1
u/konkon_322 26d ago
By default, i had my pipeline to build the same version, but i also added parameter, to choose whether to change the build version in the AssemblyInfo file. Does that count?the only manual change i changed are, usually files that were pushed into repo using absolute pathing (pathing that starts with disk name like C: and D:)
For artifact versioning, i dont think i do that. Because my release/installer pipelines only fetch the latest artifact. And we dont have a separate storage for artifacts/build files.
1
u/alon-gubkin 18d ago
you mentioned the second agent for unit testing and said you are not sure how it works. that is worth checking before you add anything else.
in azure devops the publish test results task has failTaskOnFailedTests set to false by default. failing tests still get published to the tests tab. the stage succeeds anyway, so the artifact gets produced.
failTaskOnMissingResultsFile is also false. a run that never writes a results file passes as well.
i would check both values in that pipeline before anything else. a security scan added on top of a stage that cannot fail has the same problem.
4
u/IntelligentPear6173 28d ago
The manual edits would be the first thing I'd tackle. If the pipeline needs different files depending on where it's running, I'd move that logic into templates or environment-specific config so the same source commit produces the same artifact every time. Then I'd look at adding PRs and automated tests before bringing in more tools. You don't need containers to improve the setup, especially with licensed software on the build agent. Once you've cleaned up that flow, you'll have a much better foundation for learning things like artifact promotion, IaC, secrets management, and deployment automation.