Services: Application Development

Web Development Services maintains test and production application environments to deliver university-wide, critical services to the Web. "Critical" means that if the system goes down, work comes to a halt or important information is unavailable to large numbers of individuals.We reserve this service for functions that cannot be provided in other, simpler ways. More information is provided in this section.
 If you have a need for a Web application that fits this description, this page describes how to get started.There are two ways to get your application developed:

1. If you feel you don't have the expertise to tackle this kind of a project, you can hire a Web Development student assistant. They have been trained to work with you to design and develop your system using tools available in our lab.
2. If you have the right experience, then you may want to develop the system yourself with our help. We'll work with you to make sure you have the resources you need to build software compatible with our environment. However, if you need the extra power of a MS SQL Server database, we currently require that you hire an LTS Web developer, owing to the inherent complexities and security issues involved with MS SQL Server.

Development Process

In order to securely provide support for web applications on our main campus web servers, we must take certain precautions to make sure that these applications do not interfere with the daily operation of our servers. Therefore, we have developed a process that creates a secure, stable environment.LTS Web Development must approve any application that will reside on the campus web servers. After the application has been approved, space will be created on a testing server for the developer to work and evaluate their implementation. The approval process allows LTS to allocate resources in a proportionate and fair way and also prevents developers from duplicating an existing function or application.To ensure that no development takes place on the production servers, we have separated applications from the normal web publishing space.  Developers will not have access to modify the application on the production servers. (Changes must be made on the testing server and then applied to the production servers.)Once a developer has completed an application and is ready to move to production, the application is evaluated and stress-tested by LTS Web Development staff. The code is reviewed to determine if it follows standards outlined in this document, and the application is checked for faults. Developers are encouraged to meet with LTS Web Development staff during the review of the system.If the application is found to conform to standards, it is copied to production. Developers will not have access to the production system. They will be allowed to continue development on the test environment to make any needed changes. However, code changes will require evaluation by LTS Development staff. Therefore, LTS Development encourages developers to thoroughly test systems with end users before moving to production.

Development Guidelines

We want your project to be successful. In order to do that, we have to be able to provide support for your application. That often means ensuring that the application runs long after its original developer is no longer available.The application hosting service provided by LTS Web Development Services operates under the following guidelines which we've developed to improve the support we offer. We follow these guidelines ourselves and are willing to work with you or your developer from the very beginning to ensure your project goes as smoothly as possible.

Development on Production Servers

• LTS Web Development currently supports custom applications developed with Ruby on Rails 4.0, using MySQL or Microsoft SQL Server databases.
• Application hosting is reserved for university-wide, critical functions related to UW-Eau Claire Web sites or other hosted sites that cannot be provided in simpler or more efficient ways. (Creating a web counter is an example of a project that would not be considered since our statistics provide hit counts. Wanting to create a custom CMS to make page development simpler would not be considered a legitimate project since CommonSpot templates provide similar functionality without scripting.)
• LTS Web developers are available to develop projects at no charge using a first-come first-served priority basis. This should be considered the preferred approach, especially if a project is mission critical or has needs for complex logic to obtain data from administrative systems. It may be that the entire project or parts of it must be developed by LTS Web Development.
• Space will be given to non-LTS developers if a project can be qualified. Developers must demonstrate adequate training or experience before being provided access to the test environment.
• The development process and system standards are listed briefly here: 
  • All developers work in a test environment that mimics the production environment.
  • Each system must be documented with meaningful comments before it goes into production.
  • The project will be tested to ensure it will work properly in the production environment and will go through an approval process.
  • Developers are encouraged to meet with LTS Web Development staff during the development, testing and review of the application.
  • Developers need to schedule deployments to production with LTS Web Development staff.
  • Developers should schedule deployments well in advance to ensure that deadlines are met. Applications which exhibit problems will not be placed into production until the problems are corrected, at which point the application is retested.
• Access to development space is only available to UW-Eau Claire staff or students.
• If the non-LTS developer is a student, he or she must be a member or be employed by the organization, office or department for which the system is being developed (this has to do with lifelong care needs-see below.) Developers are limited to the scripting and database environments described in the chart of services. These are subject to change.
• A source and versioning development environment is available and its use is encouraged (currently Subversion.)
• A code repository is provided for functions that must be developed in a standard way.
   Authentication is a special function for which code will be provided, but only for the languages and platforms we support. Because of privacy and security issues, it is essential that systems requiring authentication be developed properly.
• Projects developed must adhere to LTS standards for: 
  • Web standards 
    • Accessibility, valid HTML and CSS, etc.
  • Design 
    • Template use, UW-Eau Claire style guide, appropriate use of brand toolkit
  • Coding 
    • File naming, authentication, dataset calls, documentation, variable declaration, etc.
  • Documentation 
    • System documentation, user documentation, help, contact information, etc.

Lifelong Care

Once a site has been placed in production, the development does not end. Someone must be identified as caretaker of the project. If a caretaker is not available and the system malfunctions, one of two things will occur:

1. The system will be taken off-line until corrections are made
2. If this is a mission-critical system, LTS Web Development staff will make corrections. The client agrees to be billed at the current rate per hour for application development based on actual time spent on corrections.

Normally, LTS Development does not charge for development services. In this case, a charge will be required because we may need to hire additional developers to backfill other projects while we address a mission-critical application.
 Project Lifespan
All systems have a life-span. At some point, a conversion of the system may need to occur, based on changes in server technologies, Web hosting environment or scripting languages. If a conversion is needed, the client will be notified and must determine the type of staffing to be used. If this is a mission critical system and the client does not provide the staff, LTS Web Development staff will perform the conversion and the client agrees to be billed at the current rate per hour for application development.

Developer Qualifications

In order to ensure prudent use of campus resources, we require that a developer not employed by LTS Web Development can demonstrate that he or she has the necessary skills to develop an application. This helps to ensure the eventual success of the project in development.Students and staff must be able to demonstrate database and application development skills by providing code samples for our review or have met all of the following conditions:

• Have attained a passing grade in an IS or CS database course.
• Have attained a passing grade in an IS or CS application development course.
• Have a basic understanding of UW-Eau Claire Web Development guidelines including accessibility.

One year of active development in Ruby on Rails or another MVC framework with database experience is strongly recommended in order to successfully develop an application for campus use. While we can and want to help you be successful, we have limited resources available to teach you how to develop stable production applications.

Third-Party Applications

Requests for installation of third-party applications must be negotiated. The software in question must go through a selection process and must be qualified based on (at a minimum) the following criteria:

• Must be tested and run acceptably in the server environment currently available.
• If an application has needs beyond our server environment, funding and staffing needs will be identified. The application will only be qualified if those needs can be met.
• Must meet standards for Web accessibility.
• Must meet standards for browser compatibility.
• Must meet security and privacy standards.
• A standard Server SLA must be signed by LTS and the client.

Exceptions

Not all requests fit nicely into this model. Size and importance of projects, staff constraints and other issues may cause exceptions to these guidelines. Exceptions will be evaluated by the Software Systems team.

FAQs

General

• Who is required to follow these standards?
  Any person or group developing a system that will reside on one of our public web or database servers must follow these standards and guidelines. This includes application developers within LTS.
   
• Who can develop applications?
  • Students employed by the Web Development office can develop applications on our servers. These students are supervised and trained to develop applications with the appropriate tools and technologies.
  • Students employed by a department on campus who have appropriate background in application development. These students must work closely with the Web Development office and follow the procedures and guidelines.
  • Staff with appropriate training. Staff members also need to work with the Web Development office to ensure that these guidelines are followed.
      
• What types of applications can be hosted on the production servers?
  Applications that provide value to the campus community or the community at large, or applications that help to support the work of a department on campus.
   
• What types of applications cannot be hosted on the production servers?
  In order to make sure we serve the needs of our clients, we cannot devote resources to applications that have functionality that can be performed using alternative methods such as Qualtrics, CommonSpot, SharePoint, etc.

Project Sponsors

• I have a need for a web-based application for my department, office, or organization. Who do I talk to?
  Please contact us at web@uwec.edu to discuss your needs and your options. We employ student application developers that have experience building web-based applications that are happy to work with you. We may also have built a similar system to the one you're interested in.
   
• How does the development process work?
  Usually, your request to build an application is taken before the Software Systems Group, a group made up of LTS and other University staff members who review your request.  This group weighs your request against other pending requests and the current queue of work, It also looks at other existing solutions that might fit your needs. Once the request is approved, we'll assign a developer to the project who will work with you to gather more fine-grained requirements. Usually we'll slit larger applications into iterations, and you'll help us decide how features should be split. We ask that you meet with your developer once a week throughout the duration of the process so that you and the developer can both ensure that progress is made. Your developer will inform you of changes he or she has made, and you'll provide feedback on those changes. Together, you'll move the application forward. From time to time, you'll access your application from our test servers, where you and your staff will put the application through its paces and hopefully uncover any bugs or missing features before launch. When the project is completed, you'll review and sign off on the completion of the project, and your application is moved to production.
   
• What if my request to have LTS develop an application is denied?
  This is rarely the case. The Software Systems Group is designed to help you solve your problems. The group may attempt to provide you with alternatives to developing an application, such as recommendations for purchasing a third-party application, working with Campus Solutions, or working with another existing system currently in use.

Developers

• What server-side languages do you support?
  We develop all new applications using Ruby on Rails, and that is the primary platform we support.
   
• Why don't you build in .NET / Java / Python / PHP / Lisp / Smalltalk / MyFavoriteLanguage?
  Our infrastructure is designed first and foremost for the internal development of small- and medium-scale web applications. We have to pick a platform to support, and we don’t have the resources to support every language out there. Ruby on Rails gives us a testable, scalable solution based on well-known conventions, so supporting applications developed by others is much easier. You may find that learning a new language will open up new possibilities for you and may make you an even better programmer. It can also be quite fun. LTS provides various resources to developers to help them get up to speed.
   
• I am a competent developer and I should be able to test and place my own applications into production. Why do I have to use the staging area?
  The development environment in place is used by everyone, including staff and students within LTS Web Development. Applications that will reside on the web servers managed by LTS Web Development all go through the same process regardless of the developer of the system. The development environment is structured in a way that gives developers total freedom to build applications and obtain feedback from users. You may find that you don't need to move to production that often because you have ample time to test your application using the development servers. Additionally, we simply do not have the resources available to provide deployment support to every developer. If a developer placed code into production that performed poorly or broke the application, we are very likely to be called in to correct the problem because we are responsible for the server. If you do find limitations, you're encouraged to discuss this with us so that we can find a way to accommodate your needs.
   
• I’m a student and I am developing an application for a course that will be used by a department on campus. How do I get my application to move into production?
  Meet with us early before you start your project and develop your application following our guidelines. Your department will need to hire someone to maintain this application once you complete the project. Only students employed by a department can develop applications that will go into production. In some circumstances, the sponsoring department can work with Web Development to develop and maintain the application.
   
• Why does LTS care what methods I use to write my application? Why do I have to follow such strict standards?
  LTS Web Development is responsible for maintaining the campus web servers, including any applications you write. We need to be sure that your application will not compromise our web server in terms of performance, availability, or security. We also need to be able to quickly update or modify applications if needed. Often times, a student will develop a system for a faculty member or department. The system may be in production for some time before a change is needed, and that student has left the university. In most cases, LTS Web Development is asked to make changes to the application, especially in cases where database servers are migrated to new hardware or an infrastructure change requires the application to be relocated. By requiring outside developers to write applications using the same standards we use, we can improve productivity and make applications easier to maintain. By requiring outside developers to write applications using the same standards we use, we can improve productivity and make applications easier to maintain. Remember that anything you write for the university is the property of the university and reflects upon the university. Also, keep in mind that our application servers are State resources and need to be used appropriately.
   
• Where can I go for help with my application?
  LTS Web Development staff and students can assist you with simple development questions, snags, concerns, or problems. If your application requires functionality you cannot provide, you may consider hiring a student application developer.  Student developers are excellent resources because they are familiar with application development strategies as well as our development standards and requirements.

Deployment

• How long will it take for an application to be moved to production once it is submitted?
  We deploy applications on Friday mornings during the scheduled maintenance time of 4:00 AM to 7:00 AM. In order for your application to be eligible for a deployment, we ask that you submit it to us for review at least a week (7 days) in advance.  If the application passes our tests then the application is moved to production during the window and you are notified of a successful deployment. To eliminate any timeframe problems or any unwanted surprises, we want to meet with you when we test your application.
   
• Why does it take so long to move applications to production?
  We have to check through the applications to make sure they do not interfere with the day-to-day operation of the web server. This process naturally takes a significant amount of time. By making sure you have followed the standards, you should be able to create applications that will pass our testing criteria on the first try, eliminating repeated testing, thus speeding up the turnaround time for all developers, not just you.
   
• How is my application moved from development to production?
  When you've reached the point where you'd like to launch your site, contact us and set up a meeting to review your site with us. Prior to the meeting, we'll review your code and identify any security holes, performance problems, or logic issues.  When we meet with you, we'll walk through your application with you and discuss any potential issues we see. You can almost always eliminate this problem by meeting with us frequently during the development of your application so we can help you find these problems early on. Rails applications provide a mechanism to easily test both front-end and back-end logic. We expect Rails applications to have a good test suite developed upon submission for deployment. Meet with us early and often to ensure your tests are appropriate. We'll use tools to scan your code and see where tests need to be written, and we're happy to show you how you can run these same tools as you develop your code. If there are no problems, we will move your system to production during the next deployment window (Fridays between 4:00 AM and 7:00 AM). At that point, no further changes can be made to the production system unless a critical need arises.  You will be required to reschedule your deployment process after you’ve made the necessary adjustments.
   
• What kinds of things do I need to do before I request that my application be moved to production?
  1. Provide documentation of your system.
     LTS Web Development needs accurate documentation about your system so we can support it. Because we maintain the servers, we are often asked by various departments to resolve issues regarding applications running on our server. See the section on Project Documentation requirements for more information.
  2. Fix any broken links.
      We will be unable to completely test your system if broken links are found. Be sure to test all of your links.
  3. Fix any absolute path references.
      Be sure none of your links contain the full server name. We recommend using variables or constants if you have to reference server names and paths.
  4. Be sure you have read through and implemented our requirements.
      Code that does not meet our standards will not be moved to production. This includes documentation!
  5. Test, Test, Test!
     • Have good test coverage. If using Rails, use RSpec and Cucumber. Applications with low test coverage will not be moved into production, as their stability cannot be proven.
     • Have your users provide feedback on your application. Have as many people test the application as possible to ensure you have implemented all requirements. Look for possible SQL injection or URL parameter issues and try to break your validations on your forms. The bottom line is if your application crashes in any way, it will not be moved to production.
         
• How do I make changes to a production system?
  You can make changes to your production system by changing the version on the development server. When we move your system to the public server, we leave the original version on the development server so you can continue to make changes if necessary. However, changes to a system will require a completely new request to move to production. Therefore, we advise that you hold off on making changes to a system until you have a significant amount to make it worth the time.