1 / 16

Managing Software in Higher Education

Managing Software in Higher Education. James Lambert Ian Rifkin Brandeis University #NC11_SESS36. Who We Are. Your role?. Why are you here?. Software Systems Administrator Enterprise Architect. Release Management. Managing change by understanding what software is on your server(s ).

marion
Download Presentation

Managing Software in Higher Education

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Managing Software in Higher Education James Lambert Ian Rifkin Brandeis University #NC11_SESS36

  2. Who We Are • Your role? • Why are you here? Software Systems Administrator Enterprise Architect

  3. Release Management Managing change by understanding what software is on your server(s). What is release management?

  4. How? How to accomplish goals of release management?

  5. Applications at Brandeis • ~100 applications • apx. 7 million lines of code • Many are created in-house • Some open source products • Some proprietary products

  6. Our Starting Point • Software management practices apx. 4 years needed improvement • Long, unmanageable application files • Mixing of code, design, user information, IPs, etc all hard-coded in long files • Limited usage of any version control (some CVS, some RCS) • Code was often edited on the fly • 3rd party software problems too (dependencies, upgrades)

  7. Environments • Sandbox: Individual developer’s area to create/edit • Development: Unit testing • Test: Integration testing • Production: It’s live!

  8. Environment Builds • What should you do with underlying software? • Apache, Java, libraries, class files, etc

  9. Versioning Software Files Commit Changes Version Control Sandbox Get Updates • Version control software

  10. Versioning Software Files • We use Subversion (svn) • Directory structure of repositories: • Trunk, releases, branches • Directory structure within applications: • .control (encrypted password files) • bin (cron scripts) • conf (configuration files) • perllib (custom application code) • templates (HTML templates) • website (images, CSS, JavaScript)

  11. Software Kits/Builds Version Control System Get files Build Server Software Kit Group files • Builds/kits • Our builds take files from svn (trunk or a branch), groups them together with a version number, enabling them to be released.

  12. Release Scripts Software Kit Send software kit, unpack and prep for application use Application Server What should happen when you release a software build?

  13. Releases Practices • Set standards • Don’t “release and run” (esp. to production) • Consider downtime implications • Major versus minor release? • What constitutes a critical (urgent) release and what should that mean? • Who tests? • Where are bugs recorded?

  14. Communication • Communication between developers is critical • Esp. when working together on a single product

  15. Communication • Don’t rely on version control for all of your communication • Branches of code are needed at times, but add complications that need to be communicated

  16. Questions? Ian Rifkin: irifkin@brandeis.edu James Lambert: jlambert@brandeis.edu

More Related