Development environment for Software Engineering class

1
Development environment for Software Engineering
class

• Leonardo Salayandia, Steve Roach, and Evelyn
  Torres

2
Overview

• Technologies to be used
• Subversion (SVN)
• Virtual Machines (VMWare)
• Windows Server 2003
• Structure of the version repository
• Usage of the version repository

3
Disclaimer

• Im here to
• Assist with system administration
• Serve as mediator for UTEP IT
• Help you help yourself
• Im not here to
• Configure your development/test environments
• Install your databases
• Do things for you
• Symbiotic relation
• You need a grade
• I need to reuse this solution in other projects

4
Subversion (SVN)

• Successor to the Concurrent Versions System (CVS)
• Open source version control system
• Manages changes made to files and directories
• Keeps previous versions of your data
• Managing Binary vs. Text files
• Text file versions are incremental
• Binary file versions are not! (Watch out for
  space issues)

5
Subversion (SVN)
6
Subversion (SVN)

• Basic Work Cycle
• Update your working copy (update)
• Make changes (add, delete, copy, move)
• Examine your changes (status, diff)
• Possibly undo some changes (revert)
• Resolve conflicts (update, resolve)
• Commit your changes (commit)
• Read more (free online book)
• http//svnbook.red-bean.com/

7
Virtual Machines

• Virtual Machine
• Software Container simulating a physical computer
• Contains its own virtual hardware resources
• CPU, Memory, Hard Disk, and Network Card
• Runs its own OS and apps
• VMWare (VMWare Player)
• Software that runs a virtual machine
• Runs on several host OSs, e.g., Windows and
  Linux
• Another alternative
• Virtual PC (Microsofts virtual machine software)

8
Virtual Machines

• General Infrastructure
• More information
• http//vmware.com

9
Windows Server 2003

• Microsofts server OS
• Latest version is Windows Server 2008
• Your customer is using 2003
• Similar to Windows XP except that it has
• Added security features
• Administrative modules
• Active Directory (User/Computer account
  management)
• Policy management
• For the most part, administrative settings should
  be minimal for you

10
Structure of the version repository

• /dev
• /TeamX
• /Code
• /Root
• /Image
• /test
• /VirtualMachines
• /ReleaseCandidate
• /NightlyBuild
• /Root
• /TeamX
• /prod

Your development code
Your contributions to the file system of the
server in the development phase
Your contributions to the virtual machine files
(only Teams 2, 6, and 7)
VV-approved build
Automated/Semi-automated integration of teams
contributions for system testing
Each teams contributions to the file system of
the server submitted for testing
11
Structure of the version repository

• /dev
• Team2
• Root
• Image
• Code
• Team 7
• /test
• VirtualMachines
• ReleaseCandidate
• NightlyBuild
• Root
• Team2
• Team7
• /prod

• Development
• Each team has its own space
• Everybody can read everybody elses space
• Test
• Everybody can read everything
• Teams 2 and 7 modify the virtual machines
• Each team can write to its own space under root
• Prod
• Everybody can read
• Only Team 7 can write

12
Usage of the version repository

• Software development
• Decide which IDE to use, and install an SVN
  client for it
• Start your initial project and commit your
  initial version at /dev/teamX/code
• Update/Commit from /dev/teamX/code as you
  continue the development process with your peers

13
Usage of the version repository

• Unit testing
• Use the latest running virtual machines
• Synchronize with the teams that are in charge of
  the virtual machines to get connection parameters
• Get a copy of the latest virtual machine from CVS
  from /test/virtualmachines/releasecandidate or
  /test/virtualmachines/nightlybuild
• Start the virtual machine in your development
  computer
• You have both the client and the server
  machines running in your own computer to test

14
Usage of the version repository

• Deploying updates to test virtual machine
• Create deployment scripts to be run on the server
• E.g., ant script
• These scripts should install your module in the
  server
• Commit your scripts to your /dev/teamX/root
  repository as you develop the scripts with your
  peers
• Once you are ready to share with the rest of the
  class, commit your scripts to /test/root/teamX

15
Usage of the version repository

• Creating nightly builds
• Create scripts that do the following
• Stop the running nightly build VM
• For each team, get the latest version of
  /test/root/teamX
• Copy the files to the appropriate location in the
  virtual machine
• Run the deployment scripts to install the
  software
• Commit the changes to the VM when all teams have
  been processed
• Restart the nightly VM

16
Contact Information

• Leonardo Salayandia
• Computer Science, room 126
• Telephone [phone]
• Email leonardo_at_utep.edu
• I prefer going by appointment