I'm an IT administrator working primarily with Azure DevOps. This is my first job in the field, and while I enjoy the DevOps side, I'm more interested in infrastructure and networking than heavy software development.
Our current process is fairly manual. Developers work from a single branch without pull requests and push changes to an on-premises central repository. I then modify some files so the project can build on our newer agent environment. A build pipeline produces artifacts, which are passed to a separate release or installer pipeline for packaging. A third pipeline copies the installer to a NAS, writes installer metadata to a database, and sends 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 workflow and use this role to build more valuable skills. Pipeline templates seem like an obvious improvement, but containerizing the build process may be difficult because the build agent depends on licensed software.
What would you prioritize first? Are there practical CI/CD improvements I can make without containers, and what should I learn next if I eventually want to move beyond this comfortable but limited role?
3 Answers
A trunk-based workflow could be a good direction: keep the main branch as the source of truth, make small changes, and integrate them frequently. You can still use short-lived branches and pull requests for review without creating a complicated branching model.
The important part is to make the review and validation process automatic rather than relying on someone to manually prepare files before each build.
I’d start by eliminating the manual file changes between the repository and the build. Put those changes into version control, reusable pipeline templates, or environment-specific configuration. Ideally, the same source commit should produce the same artifact every time.
After that, add pull requests and required automated checks, then promote the exact same artifact through the later stages instead of rebuilding it. You don’t need containers to improve this setup, especially when licensed software is installed on the build agent. Also document and inspect the unit-test agent so the team understands what it runs and where its results go.
Security scanning would also fit nicely once the basic build and test gates are reliable. Even dependency, secret, and static-analysis checks would be useful first steps.
Once the foundation is cleaner, useful areas to explore include artifact promotion, infrastructure as code, secret management, deployment approvals, test reporting, and observability. Templates are worthwhile, but treat them as a way to remove duplication rather than as the entire improvement plan.
You can also map the current pipeline end to end: identify every input, generated artifact, manual step, test, destination, and notification. That exercise should reveal where the biggest risks and bottlenecks are before you introduce additional tools.
That’s close to how I’d like to work. I want the main branch to remain the source of truth and merge changes back after finishing each improvement.