Release pipeline review of an internal team
Couple of months back, one of my colleague in IDC mentioned that his team faces frequent issues in their release pipeline & asked about known issues. Since there were no known issues, we scheduled a review where his team talked about the issues that they were facing and Divyansh from my team & me gave recommendations on how to come out of it. In this post, I am pasting the list of issues with their recommendations so that you can also benefit from it.
| Issue | Recommendation |
| At times Azure Devops build agents fail to initialize and it happens primarily because of unavailability of disk space on agent. | Enable maintenance jobs to cleanup the agents periodically. |
| In release pipeline, we use manual steps for process reasons. These steps take lot of time during deployment. | Use manual intervention task in agentless phase in release pipeline |
| If during deployment a step fails for whatever reason, we need to start all over again starting from build generation. | Fix the release name pattern so that release names can be different for same builds. |
| Many times especially during weekends DFS store is not available for build | The internal team was using on-prem storage to store the Build output, and this had lower availability, especially over the weekend, thus making the build system less reliable. The recommendation was to use cloud storage to store their build, and expose that as an custom artifact for RM. |
| Enlistment initialization takes lots of time(>30mins) | The internal team decided to split the gigantic build package into smaller ones, only one of which was required by them. |
| Package management | The internal team abandoned their homegrown packaging system in favor of Azure Devops Package Management, which was far more reliable. |
| Internal build is not so quick or reliable | The internal team decided to abandon their homegrown build system in favor of Azure Devops Build pipelines. |
Enjoy !!