- Background
- Case Study: Interior Specialists Management System
- Remote Services
- Benefits of Deployment Under Remote Services
- Issues of Application Deployment using Remote Services
- Application Design Considerations
- Application Development Under Remote Services
- Conclusions and Recommendations
- Further Reading
Application Development Under Remote Services
So far, the discussion has focused on the benefits of utilizing remote services to access intensive business applications. However, there are also tremendous benefits to hosting the development environment that produces those applications through remote services as well. Following are some suggestions for implementing an application development server with remote services.
On your development server, you can install your remote server and provide development applications such as Visual Basic 6 or C++, Visual SourceSafe, and other necessary development tools and components. All developers and testers can then work on the development server via remote services. This demonstrates the kind of intensive application complexity that is perfectly feasible working through remote services. This strategy has many benefits, including the following:
Great performance. All developers enjoy virtually the same performance, regardless of the age of their local machine. The usual complaints about local hardware capability are not an issue. Development machines do not need to have the hottest specifications available.
No special coding considerations. Since programs can be written as stand-alone, none of the limitations or complications of browser-based programming exist. Huge problems like maintaining state across web pages become non-issues.
Local system independence. Developers like to play with the latest of everything. If they are accessing their development environment through remote services, they can do anything they like to their local machines without breaking their development environment and causing project interruptions.
Ease of setup. New developers coming on the project only need to do a five-minute remote services client install and configuration. They then have access to the full development environment. When developers leave the project, there is no need to ensure that their code is moved over and no more hunting through their systems for passwords and lost code. There is substantially less to clean up on workstations before giving them to new developers on new projects. Using a dedicated development server through remote services, the developers can work on multiple projects simultaneously without reconfiguring their local systems.
Remote development. Developers or other team members can connect to the development server from anywhere and have full access to their development environment. They are able to work from anywhere at any time without carrying removable hard disks in their briefcases. Developers who leave the project can easily connect remotely if needed. If third-party technical support is required, they can access the full development environment via remote services as well.
Ease of deployment. Testing can be performed on the development server or on a separate test server. In either case, weekly or daily test builds are a simple matter of compiling. There is no need to create and maintain installation applications to deploy to testing machines. For client acceptance testing and review, there is no need to provide installation applications to them, they simply log in remotely.
One set of code. All of the project code, files, and documents are stored on the development server, and all developers <can> work on a single set of code. Doing so eliminates all the usual mistakes and issues caused by multiple sets of code floating around. Because all project-related information resides only on one box (plus external system backup media), it can be easily handed over to the client or another firm with complete confidence on both sides that it included all materials in a working state. Code security is increased because there are not multiple copies floating around. Source control and backups need to focus on only one server.
No component compatibility issues. There are none of the usual day-to-day issues resulting from new component versions or component incompatibilities on local machines. Because all components are located in one place, there are no hard-to-fix registration issues introduced by developers working on components on different machines.
Production environment during development. If the application is to be deployed under terminal services, there is a tremendous benefit and inherent confidence generated by developing and testing the project under that same environment. Also, because development occurs on a multiuser system, any multiuser issues are exposed early.
Of course, there are some negatives associated with application development in a multiuser environment. One consideration is whether to use a single code set, or to have a code set for each developer on the server. For the ISI project, a single code set was used. This avoided many problems resulting from multiple code sets. The only "gotcha" in that regard is that Visual SourceSafe is not designed to work this way. However, after developers learned never to use the "Get Latest" option, no issues were encountered in sharing code, and most typical problems were avoided completely.
There is also a problem when developers try to build shared components when other developers are working on projects referencing them. This is a nuisance, but even if developers were to build ActiveX components locally, everyone would have to be out of projects referencing them to move them to the server in any case.
There are psychological barriers that some developers experience when asked to work in a shared environment. One is the feeling that they are dependent on a server rather than their local machine. However, developers quickly come to realize that the servers offer great performance and reliability, and allow them more flexibility in what they do with their local machine and from where they can access their development environment.