Ste*_*mul
24
The Complexity of Deployment
Only the simplest applications can work with a simple file copy, and even then you need to have a convenient way to actually download and do the copying of the files to the right location - and this is what a setup is for. The setup is also a marketing tool that can be used for branding and consistency across products as well as allowing installation of a trial version of the product - a very important part of selling software.
最后,设置为新版本提供升级和修补功能,以及在用户想要删除软件时卸载和清除系统.也可以使用数字证书对良好的设置进行签名,以确保文件不会在传输过程中受到阻碍,并且供应商可以认证并因此严重.所有这些对于严肃的产品都至关重要.
重要的是要记住,设置体验是用户首次遇到产品质量.如果设置失败,则根本无法评估产品.这似乎是软件开发中最昂贵的错误.
部署中的错误是累积的,因为一旦您遇到已部署的错误,您通常无法访问有问题的计算机进行调试 - 修复程序很容易造成更多损害.您正在管理交付流程,而不仅仅是调试代码和二进制文件.每次交付都会增加风险和复杂性,如果您不小心,很快您就无法维持在手上.此外,运行设置的所有机器几乎肯定会处于与另一台计算机完全不同的状态.
Deployment (setups) is therefore the complex process of migrating any computer from one stable state to another. This requires a disciplined approach. The setup should install all required files and settings and ensure the product is configured for first launch or ready to be configured upon launch without failure. This can be a very complex task. The list of things a setup may need to do is growing all the time, and for every new versions of Windows it seems new obstacles are put in place to make deployment harder. Such obstacles include the UAC prompts, self-repair lockdown on terminal servers, changed core MSI caching behavior, new folder redirects, virtualization features, new and changed signing features with encryption and digital certificates, Active X killbits security lockdown, 64 bit complexities, etc... The list goes on.
Application virtualization is a big issue these days. It essentially encapsulates computer programs from the underlying operating system on which it is executed. This essentially still involves a deployment package for your application, but a fully virtualized application is not installed in the traditional sense. The application behaves at runtime like it is directly interfacing with the original operating system and all the resources managed by it, but can be isolated or sandboxed to varying degrees.
An Overview of Deployment Tasks
The tasks and features needed in a setup range from the very fundamental and basic with built-in Windows Installer or third party tool support, to the highly customized ad hoc solutions where you have to actually code something yourself to deal with unique deployment requirements.
部署工具确实包含了您在任何部署中所需的大部分工具,但某些事情仍然根据具体情况进行编码.这些临时解决方案在Windows Installer 中实现为" 自定义操作 ",毫无疑问它们是部署失败的主要原因.有关自定义操作的更多信息,请参阅"非常高级"部分.
Overuse of custom actions and a lot of ad hoc coding tends to indicate flawed application design, but in certain cases you are just dealing with new technology and you have to roll your own solution to get your solution deployed. This is exactly what custom actions are for. Over time standardized solutions should be created and preferred. And small changes in application design can often eliminate complicated custom actions. This is a very important fact about software deployment - there are so many variables that one should opt for simplicity whenever possible.
At a basic overview level, deployment must account for:
Setup Fundamentals
所有第三方工具都为这些设置基础提供了良好的支持,但存在一些差异.在编写本文时,先决条件的安装可能是第三方工具和免费框架(如WiX)在易用性方面差异最大的领域.有支持,但设置起来可能有点挑战.
- 检查系统是否适合安装相关包装.
- 磁盘空间.
- 操作系统类型和版本.
- 语言版本.
- 计算机体系结构x86/x64.
- 不合适的平台:瘦客户端/ Citrix /终端服务
- 甚至可能是恶意软件情况(我希望 - 可能导致神秘的部署问题).
- 等等...
- 扫描存在,并在必要时安装先决条件和运行时.
- 允许轻松部署先决条件和运行时是第三方部署工具中广泛支持的任务.Windows Installer本身对此的支持有限.Windows Installer中运行时分发的基本功能是合并模块 - 实质上是MSI文件的"包含文件等效".部署共享文件的标准方法.合并模块在构建时编译到您的MSI中 - 在开发人员术语中进行早期绑定.
- 某些先决条件是通过Windows Installer合并模块安装的.其他通常使用自己的安装文件(各种格式)安装.
- Examples: Active X for games, Crystal Reports, Microsoft Report Viewer Runtime, MySQL, SQL Server Runtime, VB6 Runtime, ASP.NET MVC Runtime, Java Runtime, Silverlight, Microsoft XNA, VC++ Runtime, .NET runtime versions, Visual Studio Tools For Office Runtime, Visual F# Runtime, MSXML Runtime, MS Access Runtime, Apache Tomcat, Various Primary Interop Assemblies, PowerShell versions, etc...
- Finally, several core Microsoft components such as Windows Installer versions and PowerShell versions generally come down via Windows Update and might be better to exclude from your setup (just check for existence, and tell user to run Windows Update if component is missing). Actual practice here varies.
- Provide a GUI suitable for input of required settings from the user.
- It is common practice to enter and validate license keys in a setup.
- Personally I think this is better done from the application itself for both practical and security reasons - making piracy more difficult, allowing trial installs, reducing excessive setup support calls (you wouldn't believe it...), etc...
- 对于复杂的设置,可能需要很多GUI来收集部署设置 - 特别是对于使用IIS,MS SQL,COM +和其他高级组件的服务器设置.
- 允许以静默方式安装以供企业使用.
- 非常重要 - 除了某些服务器安装外,所有企业部署都是自动且安静的(安装期间未显示GUI).
- 较小的公司可能会在GUI模式下运行您的设置.根据我的经验,他们通常会这样
- 家庭用户通常总是在GUI模式下运行您的设置.
- 了解您的目标群体,如果您定位企业客户,一定要确保您支持静默运行.但是,所有设置都应该以静默模式工作,如果您遵循MSI设计规则和最佳实践,它"免费".
添加基本资料
These basic tasks have full support in the Windows Installer engine itself, and all third party tools provide fairly equivalent support for all of them despite variations in GUI features and ease of use.
- Install files and registry settings.
- Install odbc, file associations, shortcuts and icons.
- Update application and system-wide path settings.
- Update and merge text based files such as INI files.
- Register COM files and enable .NET COM Interop if need be.
- Install .NET assemblies to the GAC, and run custom .NET installer classes.
- Install side-by-side windows assemblies to WinSxS.
- Deliver signed and certified files (also applies to the setup file itself).
- Install and control Windows services.
- Install Control Panel Applets.
- Update environment variables.
I won't dwell on these issues or flesh them out with too many details. All of these deployment tasks should be reasonably well supported in all deployment tools and frameworks available. However, many people mess up their deployment by not using the built-in deployment features and instead relying on custom actions for such trivial tasks. Entirely added risk for no gain whatsoever.
In particular we often see custom actions used to install Windows services - and this is usually a sign of a very badly designed service, or at other times just ignorance of how to do deployment. Both issues together is also common. Deploying such a service often involves applying custom ACL permissioning and modified NT privileges to make a service run with user rights instead of as LocalSystem - which is generally the only correct way to run Windows services. Running a service with user credentials is a "deployment anti-pattern" worth mentioning in passing (more on this later).
Another common custom action use that is always wrong is to install files to the GAC via a custom action. There is good built-in support for this in Windows Installer and any excuses to install via a custom action is almost certainly hiding a bad design or some generalized madness :-). It is also a fact that many deploy far too many things to the GAC overall, but that is a development issue: When should I deploy my assemblies into the GAC?
Finally, .NET installer classes are intended for developers to test their components during development - it should not be used for deployment. It is essentially just the .NET equivalent of self-registration (which is also not acceptable for MSI - you need to extract the COM information and add to the MSI tables - see link for details). An MSI is declarative - it should contain all changes to be applied to the system so that proper rollback and management can be ensured. So the message is that .NET installer classes should only be used for development and testing. Once you build an MSI to deploy your application you should use MSI constructs to achieve proper deployment with rollback support and intelligent management. We see these .NET installer classes used mostly for service and GAC install. In an MSI this translates to using the ServiceInstall and ServiceControl tables for services, and just marking a component for GAC install to install to the GAC (must be a signed assembly). Once you know how, it is easy and you won't miss the .NET installer classes because MSI works like "automagic" when you do this right. You get reliable rollback for free, with ease.
Adding Advanced Stuff (often server stuff)
Despite support in all deployment tools for most of these issues, I have often found that I needed to implement custom actions and ad hoc solutions to achieve proper deployment in certain cases. This is particularly the case for COM+ and IIS deployment. WiX provides highly customized support for both types of deployment, but I have limited experience using it.
The update and installation of XML files is a task supported by each deployment tool since there is no built-in support for this in the Windows Installer engine - which is quite amazing at this point.
With regards to database installation and particularly updates, I am on the fence thinking it should be done from applications with proper user authentication and interactive use, instead of a "one shot" and impersonated deployment operation (that might fail seemingly without good exception management or recovery options). Or in other cases it seems updates should be a managed process involving users raising corporate tickets handled by professional DBOs. Some more details below.
- Configuration of IIS, Apache, or other web servers.
- This is a whole world of its own, particularly with regards to IIS. I have found deployment tools lacking in features to deploy sites as requested by developers and corporate teams.
- Though largely untested by me, the WiX framework provides a very flexible implementation of IIS configuration and deployment.
- I expect a lot of custom actions are in use to achieve special deployment configurations.
- Run SQL server scripts against databases.
- Create db, connect to db, update db, run stored procedures, maybe even trigger backups or schedule new tasks, etc... I don't know all that people do here.
- Should this be done in the application instead, or by a DBO? That seems much more reliable. A setup is "one shot", an application can be restarted and you try again - a better exception handling.
- Plus an MSI setup has a highly limited GUI severely limited in events due to the overall MSI design (proper Win32 dialogs can be spawned from the limited MSI GUI, but it takes a lot of effort - I have only done it once).
- Crucially a setup can run with elevated rights, but that is just on the local machine. Authentication is still needed against the database (unless Windows Authentication is used).
- A database update is a transaction on its own that would run as a part of the overall Windows Installer transaction. It is not obvious how to handle errors or what to do in terms of rollback if the installation fails.
- Needless to say this can all get very complex to handle in your setup. It is an (enterprise) configuration task in my view, not just a deployment task. Insightful comments very welcome on this issue - I am on the fence with regards to best practice.
- If you are delivering a client/server solution to your customers and need a way to set up the (server side?) databases "fresh" with defaults to help your customers "get going" with your solution, then database deployment definitely makes sense to me. But update scripts run as part of installation targeting existing databases would worry me in terms of reliability and management - not to mention safety.
- For corporate database updates it would seem a proper process involving a DBO would be more secure. They can run a proper backup before updates are applied and then true rollback is in place if problems are found in UAT.
- Installing ActiveX browser components (certificate based through browser).
- Install of signed CAB file downloaded from a Web page (admin only, can be captured as an MSI for mass deployment with elevated rights).
- Defaults to install in "C:\Windows\Downloaded Installations".
- Complications can arise if the version in the CAB file differs from the version requested by the Web page (triggers CONFLICT folders to be generated as installs keep re-running).
- Update and merge XML files.
- Advanced because it is (amazingly) not natively supported by Windows Installer.
- Supported with extensions by both WiX and third party deployment tools.
- Configure and control COM+ components.
- Tech note: I have failed several times to achieve this properly with several third party tools. There seems to be an overall lack of required features.
- I normally end up manually configuring the COM+ application and then exporting an MSI from the Component Services administrative tool that is then used for deployment.
- This exported MSI is not good at all - fragile if you try to make any modifications. It contains an undocumented .apl file with the application's attributes and any dependent DLL or data files are not auto-included.
- WiX provides support for COM+ (not tested at all by me). I hope it is good :-).
- Just for reference: Understanding COM+ Application Installation.
- Add custom event logs, set up performance monitors, add firewall rules, and other windows extensions. Supported by most deployment tools these days - including WiX. These features are not natively supported by the Windows Installer engine.
- Set up connections to mobile devices and deploy.
- Can involve "some strangeness" and weird proprietary solutions.
- A custom, native dll might be required to achieve smooth deployment (Pocket PC back in the day - not sure how things work these days).
- Install drivers of various kinds.
- Much easier and more reliable now for signed drivers than before.
- Supported by all third party tools and WiX (using dpinst.exe in the background).
- Hooking up the application to advanced server features (deployed separately).
- Automatic update systems.
- License servers. Floating licenses, or regular licenses.
- Online resources of various types. Help, templates, discussions, SDKs, developer tools, etc...
- Online stores.
- Most of the time this just involves setting a link or registry key to point to the server resources, but sometimes it is more complex.
Adding Very Advanced Stuff (custom actions)
- When there is no built-in support for a certain operation or task in Windows Installer itself, or in any of the various third party tools available, you are left having to implement the feature yourself.
- When you use Windows Installer, this involves running custom actions of various types (Windows Installer's mechanism for running executable, custom installation logic during installation).
- Custom actions are purpose built executables (binaries: dll, exe) and scripts capable of making advanced modifications to the system during installation that are not supported by Windows installer natively or by the deployment tool in use (WiX, Installshield, Advanced Installer, etc...).
- Custom actions that make modifications to the system run with elevated rights so that changes can be made to the system even if the logged on user does not have admin rights. There is essentially no limit to what these custom actions can do. They are armed and dangerous.
- Custom actions are the leading causes of deployment errors