Azure DevOps数据库单元测试登录失败求助：本地及SSMS验证正常

嘿，我来帮你捋捋本地能正常跑但Azure DevOps单元测试任务连Azure SQL时登录失败的可能原因——这种本地和CI环境不一致的问题确实挺磨人的，结合我碰到过的类似情况，给你几个排查方向：

• Azure SQL防火墙没给DevOps代理开权限
  你本地机器的IP肯定已经在Azure SQL防火墙的允许列表里了，但Azure DevOps的代理（不管是微软托管的还是你自己搭的自托管代理）的IP大概率不在里面。如果用的是微软托管代理，它们的IP是动态变化的，你可以先试试在Azure SQL的防火墙设置里开启「允许Azure服务和资源访问此服务器」这个选项；要是自托管代理，就得把代理所在机器的公网IP加到防火墙规则里。
• 连接字符串的配置出了问题
  本地测试时连接字符串可能存在本地配置文件或者硬编码了，但在DevOps管道里，你大概率是用变量组或者管道变量来存用户名密码的。这时候要检查：变量有没有正确注入到连接字符串里？比如密码里的特殊字符（像@、$、!这类）有没有转义？会不会变量名拼写错了，导致实际传进去的是空值或者错误值？另外再核对下连接字符串里的服务器名称，别多打少打了字符。
• 身份验证或安全策略的坑
  要是你本地用的是Windows身份验证，但DevOps代理跑在非域环境里，那肯定登不上。就算是SQL身份验证，也得检查下Azure SQL服务器的「Active Directory管理员」配置有没有问题，或者是不是账号因为多次错误尝试被Azure的安全策略暂时锁定了——你可以去Azure门户的SQL服务器「安全」->「登录名」里看看目标账号的状态。
• 自托管代理的运行权限不够
  如果你用的是自己搭的自托管代理，它运行的服务账户可能没足够权限访问网络，或者读不到存储密码的安全资源（比如用了Azure Key Vault的话）。得确保代理的运行账户有读取Key Vault密钥的权限；要是用的是管道秘密变量，也得确认变量设成了「秘密」类型，并且在管道里能正常引用。
• 单元测试的上下文差异
  本地跑测试是在你的用户上下文里，而DevOps里是在代理的服务上下文下。有些测试代码可能偷偷依赖本地的环境变量、证书或者其他配置，这些在CI环境里没有，结果看起来像是登录失败，实际是其他依赖缺了。你可以在DevOps任务里加个「命令行」步骤，打印下连接字符串的实际值（注意别泄露密码），或者用sqlcmd命令测试下用相同的用户名密码能不能连上Azure SQL，先排除是不是测试代码本身的问题。

内容的提问来源于stack exchange，提问作者KMM