IT 관리 외부에 powershell 적용

Question

우리는 자동화 엔지니어가 매개 변수화되고 제어 흐름에 통합 된 수천 개의 작은 논리 단위를 구성하는 대형 응용 프로그램을 구성하는 유연한 프로세스 제어 시스템을 보유하고 있습니다.

세분화 된 수준에서 반복적 인 많은 작업이 있으며이 요구 사항을 충족시키기 위해 만들어진 많은 독점적 생산성 도구가 있습니다. 우리는 서로 다른 사업 영역을 가지고 있으며 자동화 기술자는 기술 집합과 관심 분야에서 전 분야에 따라 다릅니다. 멋진 GUI와 유용성 대 유연성은 일반적인 논의입니다.

언뜻보기에 powershell은 이러한 툴링을 구현하는 현명한 플랫폼 인 것으로 보이며 전체적으로 시스템 설정 및 배포의 IT 측면을 관리하는 데 유용한 크로스 오버 스킬입니다.

이것은 스크립트가 원하는 융통성 (이미 스크립트를 쓰고있는 군중)을 잘 알고 있어야하며 GUI 의존도가 여전히 powershell에 의해 지원되는 원하는 GUI를 얻을 수 있습니다.

그러나 이질적인 사용자 커뮤니티를 수용하기 위해 광범위하게 powershell의 스크립팅 기능과 객체 전달을 사용하려고 시도한 많은 사람들/그룹을 찾을 수없는 것 같습니다. 외부 IT 관리 영역.

아무도주의 사항이나주의 사항이 있습니까? 왜 이런 일을해서는 안되는 지 분명하지 않습니다.

powershell이 ​​전 세계를 대신해서는 안됩니까? ;-)

Answer 1

전적으로 동의합니다. 전 세계가 PowerShell을 인수해야하며 귀하의 진술은 PowerShell이 ​​향하는 곳입니다.

PowerShell을 통한 GUI는 많은 의미를 갖습니다. 나는 스크린 캐스트를했다 How to Host PowerShell in a WPF Application

Microsoft Exchange의 GUI는 모두 PowerShell 위에 겹쳐있다. 명령 줄에서 할 수있는 GUI에서 수행 할 수있는 작업. Exchange는 GUI 단계를 "기록"하고 PowerShell 스크립트로 제시 할 수도 있습니다.

이 경로를 사용하면 학습 곡선이 올라갑니다. PowerShell 엔진, 실행 영역, PSObjects 컬렉션, 오류 처리 등을 포함합니다.

아직 많이 없습니다.

Answer 2

Powershell은 분명히 이런 종류의 작업을 수행 할 수 있으며 시간이 지남에 따라 더 많은 능력을 갖게 될 것입니다. 또한 유연하고 확장 가능하므로 추가 할 필요가 있습니다. 분명히 그것의 지원 수명은 수십 년 안에 측정 될 것입니다. 분명한 단점은 공급 업체 lockin입니다.