Workshop 7

Workshop 7

End of the Line: production site migration and maintenance

The options to arrange and maintain the OTBS are various, which depends on experiences about the deployment team. Ruby on Rails has a variety of ways for deployment, for instance the company deploy to an in-house hosting setup. It means that we would have to take in consideration skilled staff to perform maintenance and the cost-effective hosting equipment, otherwise the company could deploy to an external hosting service. Technical methods for deploying the OTBS could use either Phusion Passenger or Ruby Enterprise Edition. Thus, IT manager could take advisement from the deployment team So, the manger’s responsibility is to supervise the deployment of the OTBS from a holistic approach.

What are the hosting solutions?

For the host, the OTBS in-house would request available technical staff in order to act maintenance or outsource the maintenance to a third party. The OTBS can be hosted by a standard hosting company that has more knowledge and understanding about Ruby on Rails for supporting software, such as Rails Machine, engineyard and even an Australian host provider Anchor.

Will our Rails applicatoins run on a cloud computing service in the feature?

By testing the hosting capacity about engineyard, the cloud computing is a viable option for Ruby on Rails in the future. Currently many Ruby on Rails applications are upgraded or used by small businesses. Cloud computing hosting service supports relatively low price option for a company to run their Rails applications on the Internet without the heavy expenditure for technical staff and equipment. After a cloud computing services, it will look like the public cloud option which has the capacity to care small sized business. Businesses are going to size up to a Fractional Cluster service. This provides comparatively more expensive, though higher level of service. There are a range of hosting plans that should suit many organizations which prefer not to be involved or outlay the expense of maintaining their own in-house hosting. Cloud computing provides an inexpensive alternative and allows the company to concentrate on their core service. Even if Yapp does state that computing cloud could be a main advantage in lowering costs and the contribution from IT to environmental sustainability (2009). Service level agreements require to ensure that performance is maintained and does not eat up the cost saving. But Yapp points out that cloud computing could have some side issues, such as security and interoperability. However, for Ruby on Rails, it has a future at least for small to medium size business which does not want to outlay expense to host their web application in-house.

IT INFRASTRUCTURE MANAGER’S THREAD

To Do:

To begin with, deployment and maintenance plan used to deploy the OTBS for internal and external host provider. Those are briefed below,

• Deployment Plan

Deployment Planning: First of all, there is a requirement to illustrate every activity performed in deploying the product to the server site. This will contain planning, beta testing, preparation of any materials needed to be delivered or purchased, installation, training as well as support.

Responsibilities: To define the responsibilities to be performed by the development team with the preparation for deployment.

Schedule: To identify both schedule and milestones in order to conduct the deployment activities. Deployment milestones require the conforming to the project milestones. So, the deployment workflow should be considered to deployment planning, support material development, acceptance test management, acceptance testing at the development site, acceptance testing at in-house or hosted site, producing the deployment unit, and beta program management.

Resources: To build list of resources and their sources are needed to carry out the planned deployment activities.

Facilities: To explain the facilities required to test and to deploy the OTBS, so that such facilities will contain special buildings or rooms with raised flooring, power requirements and special features to support privacy as well as security requirements.

Hardware: To identify the hardware required to run and support the OTBS. Specify model, versions as well as configurations, and it provides information about maintenance support and licensing.

Budget: To revises cost for resources in order to meet deployment goals.

The Deployment Unit: To make a list about the software and documentation that is provided as part of the OTBS.

Support Software: Describe all the software such as tools, test data, utilities, CM tools, databases, and data files to support the OTBS.

Support Documentation: Describe the documentation such as design descriptions, test cases and procedures, and user manuals to support OTBS.

Support Personnel: Describe the personnel and their skill levels, required to support the OTBS.

Risk Management: To develop a risk management plan, dealing with contingency plans for the OTBS.

Training: To describes the plan and inputs for training the end user such that they can both use and adapt the OTBS.

Test the plan: After the plan is accomplished, the plan tests it thoroughly. Verify all deployment strategies and identify any potential issues. Then update the plan based on test results.

Review plan: The deployment plan should be finalized before OTBS deployment, thus each project team should review and accept the contents of the plan before deployment begins.

• The Maintenance Plan

The maintenance plan offers support with necessary information in order to maintain an IT system effectively. This plan briefly defines the support environment, roles and responsibilities as well as scheduled activities, whether or not OTBS is in-house.

The next step is to define the support environment, roles & responsibilities, maintenance activities. If outsourced then determine the level of support for example support will include two main releases, following all possible changes and a help desk will be maintained and technical support will be provided as required. The period of support will be 3 years from post deployment. This support will be on an on-call basis to review requirements and any updates. And then, it determines maintenance activities as required, if outsourced insure they are covered in the SLA. Later, monitoring the system for continued performance is required to provide the necessary system modifications before users report it. After that, the plan needs to ensure regular backups or transactional log backups are performed, and then tests the backup files periodically to ensure they have not become corrupt. Especially, it backups the data removed from the premises and held in secure location. Later, it ensures the application upgrades, patches and enhancements are applied when available. If hosted off site ensure the Service Level Agreement (SLA) states that the hosting organization is responsible for the upgrades and patches. After that this plan ensures general inspection of database in order to check database integrity and monitor database size to determine whether to grow or shrink databases. Then, it identifies the support environment, including the development, maintenance, and target host environments, and provides information on the procedures necessary for developers to maintain the software. Then, track tasks in the maintenance tracking, server maintenance and maintenance log spreadsheets. After that, finally, the risk management policy requires to be implemented.

References

Yapp, C. (2009). Making a cloud real. ComputerWeekly.com. Retrieved Oct 21, 2009 from http://www.computerweekly.com/Articles/2009/05/08/235956/making-the-cloud-real.htm

Klariti.com (2009). Deployment Plan template Retrieved Oct 21, 2009 from http://www.klariti.com/deployment-plan-template/

Klariti.com (2009). Maintenance Plan Template Retrieved Oct 21, 2009 from http://www.klariti.com/templates/Maintenance-Plan-Template.shtml

Pigoski, T.M. (2008). Template for a software maintenance plan Retrieved Oct 21, 2009 from http://www.techstreet.com/direct/SWM_samples.pdf