2010-03-13 29 views
4

我们拥有一个灵活的过程控制系统,自动化工程师通过该系统配置大型应用程序,其中包含数千个小型逻辑单元,这些小型逻辑单元已参数化并集成到控制流程中。在IT管理之外应用powershell

在粒度级别上有许多重复性的任务,并且有许多专有的生产力工具可以满足这种需求。 我们拥有不同的业务部门,自动化工程师在技能和兴趣方面各有不同。花哨的GUI和可用性与灵活性是一个常见的讨论。

乍一看,PowerShell似乎是实现这种工具的一个明智的平台,并且这也是一个有利的交叉技能来管理整个系统设置和部署的IT方面。

这应该使脚本能够理解他们想要的灵活性(他们已经是一个脚本编程人群),而且依赖于GUI的人仍然可以获得他们所需的基于PowerShell的GUI。

但我似乎无法找到很多试图广泛使用powershell的脚本编写和对象传递来容纳异构用户社区以外的IT管理领域的人。

有人有任何提示或警告词吗? 我错过了为什么不应该这样做明显的东西?

Powershell不应该接管世界吗? ;-)

+0

你现在用什么? – Knox 2010-03-13 12:08:59

+0

我们使用一些工具来传递太多细节。不同的业务部门具有不属于原始软件一部分的利用/工具支持。这种方法的另一个好处是接收标准的cmdlet /提供者遵守原始开发者的正式模型,而不是旁观者。 – Tormod 2010-03-13 23:07:21

回答

5

我完全同意你,PowerShell应该接管世界,你的声明是PowerShell的标题。

PowerShell上的图形界面使得它有很多意义。我做了一个截屏视频How to Host PowerShell in a WPF Application

Microsoft Exchange的GUI都是通过PowerShell分层的。您可以在GUI中执行的操作可以在命令行中执行。 Exchange甚至可以“记录”GUI步骤并将它们呈现为PowerShell脚本。

通过这条路线可以学习到你的学习曲线。嵌入PowerShell引擎,运行空间,PSObjects集合,错误处理等等。

还没有太多。

1

Powershell显然能够完成这种工作,而且随着时间的推移它只会变得更有能力。它也灵活且可扩展,因此您需要添加内容。显然,它的支持寿命将以几十年来衡量。显而易见的缺点是供应商锁定。

+1

我想我们很早以前就把我们的灵魂卖给了MS。作为一名.NET开发人员,在这方面我觉得自己就像一个大天使;-)但是你的观点很好。 – Tormod 2010-03-13 23:09:39

相关问题