I'm an IT administrator working mostly with Azure DevOps. This is my first role involving DevOps; I studied computer science with a networking focus, but I'm more interested in infrastructure and automation than heavy software development.
Our current process uses a single development branch with no pull requests. Developers push code to an on-premises central repository, then I manually modify some files so the project can build on our newer agent environment. We have separate pipelines for building the software, packaging the build artifacts into an installer, and then distributing the installer to a NAS, writing metadata to a database, and sending a formatted notification email. We also have a second agent dedicated to unit testing, although I don't fully understand how that part currently works.
I'd like to improve the process and introduce practices or tools that will help me grow. Templates seem like an obvious improvement, but containerizing the build may not be practical because the build agent depends on licensed software. What would you prioritize in this situation, and what DevOps practices could improve the workflow without requiring containers?
3 Answers
I’d start by eliminating the manual file changes during the handoff. Those modifications should live in version control or in reusable pipeline templates, rather than being performed manually each time. If different environments need different settings, use environment-specific configuration or templates while keeping the application source consistent.
After that, add pull requests and branch policies, then make sure the unit-test pipeline is visible and understood by the team. A good next step is artifact promotion: build an artifact once, validate it, and promote that exact artifact through later stages instead of rebuilding it. Containers aren’t required for any of these improvements, and licensed software can remain installed on a dedicated agent.
A trunk-based workflow could work well here. Keep the main branch as the source of truth, make small changes, and merge them through pull requests after automated validation. You don’t necessarily need a complicated branching model; the important parts are review, automated checks, and keeping the main branch healthy.
I’d document the build and release stages as well, especially the unit-testing agent. Understanding what triggers it, what it validates, and where its results go will make it much easier to improve safely.
You can still use the main branch as the canonical source while requiring a pull request before changes are merged. That gives you review and quality gates without creating a large number of long-lived branches.
Once the manual work is under control, you can expand into artifact management, infrastructure as code, secrets management, deployment approvals, and better monitoring. Templates are a good starting point because they reduce duplication across pipelines and make the process easier to maintain.
I wouldn’t add tools just for the sake of having a more impressive toolchain. First make the existing process reproducible, traceable, and automated. That foundation will teach you more than immediately introducing containers, especially when the build depends on licensed software installed on a dedicated machine.
Security scanning would also fit naturally once the basic flow is cleaned up. Even simple dependency, secret, and static-analysis checks can catch problems before an artifact is released.