powershell - PowerShell - 分布式解决方案

Question

我是 PS 新手，所以我可能会弄错一些术语。

如果您想为 30 名开发人员/DBA 的团队推出自定义 PowerShell 环境（管理单元）。最好的方法是什么……如果您打算每周推出一次新功能？PowerShell 2.0 在这方面有帮助吗？

假设：
安装 PowerShell（v1 或 v2）的团队中的每个人都没有问题

更新：另请参阅下面关于 v2 的 Jeffrey Snover 的回答。

Answer 1

这将在一定程度上取决于您打算进行的功能更改。对于我们的环境，我们推出了一个非常标准的 PS 安装，然后在每个人的配置文件中添加一行，以从服务器上的共享文件夹运行脚本。然后在该脚本中，我可以进行任何我想应用于每个人的自定义。

我们将这条线添加到机器特定的 MS 配置文件（%Windir% 中的那个），这是一个有意的选择。我们这样做是为了让用户基本上只能在他们的生产盒上得到这个。这样，当他们编写一些东西时，他们可以快速登录到测试框并运行脚本，以确保脚本将在不依赖这些定制的情况下部署。

目前，定制非常普通。大多数只是一些添加的功能和别名。我还有一个专门为 powershell 用 C# 编写的记录器，因此它从同一个网络文件夹中的 dll 加载它。

因为我经常在我的环境中玩耍，所以我的个人资料中有这个:)

$ProfileDir = ([System.IO.Directory]::GetParent($profile)).FullName
$localMSProfile = "$PShome\Microsoft.Powershell_profile.ps1"
$localAllProfile = "$PShome\profile.ps1"
$userAllProfile = "$ProfileDir\profile.ps1"
$userMSProfile = "$ProfileDir\Microsoft.Powershell_profile.ps1"
$allProfiles = ($localAllProfile, $localMSProfile, $userAllProfile, $userMSProfile)

Answer 2

这就是我们在 PowerShell V2 中添加 MODULE 支持的原因——它是 xcopy 部署函数集的最简单机制。模块文档在这一点上非常简单，但在一两个月内应该会好得多。

实验！享受！从事！

Jeffrey Snover [MSFT] Windows 管理合作伙伴架构师

Answer 3

如果您每周推出一个新版本的管理单元，那么切换版本可能对这部分事情没有帮助。但是，您将在一个更新的平台上进行开发，并利用它附带的扩展功能的优势。

正如已经建议的那样，一些脚本可以减轻部署的痛苦，以至于您只需正确维护这些脚本并继续生成新版本即可。