1. Presented by: Katie Morgan Pacific University August, 2014 Managing Colleague Custom Software

2. Session Rules of Etiquette Please turn off your cell phone/pager. If you must leave the session early, please do so as discreetly as possible. Please avoid side conversation during the session. 2 Thank you for your cooperation!

3. Introduction The topic of how to structure your custom projects, workgroups, packages, and update groups was a hot topic at the Ask the Guru session at a recent conference. The package structure then feeds into custom impact reports. But there’s more to impact than meets the eye. 3

4. Agenda The “layers” of custom resource “groupings” Various approaches to grouping custom resources How to find all custom resources impacted by Ellucian updates 4

5. Projects, workgroups, and packages! Oh, My!

6. “Layers” Overview Projects Workgroups Packages Update Groups 6

7. Projects: Defined A project is “the basic working unit for organizing and maintaining a group of files in a Colleague Studio workspace” It’s really just a folder containing resources – That you are creating – That you are modifying – That you are using for reference/research/information 7

8. Projects: Things to Consider Projects are local only. – You can name them anything. – You can only manage them from within the Colleague Studio workspace they were created in. A project can only tie to a single Colleague environment. The same resource can be in more than one project. 8

9. Workgroups Workgroups are groupings of resources that allow for management of custom vis à vis the local product repository (lpr). You manage them primarily within Colleague Studio. – Some UI forms exist for inquiry and limited maintenance. 9

10. Projects vs Workgroups A project can only be tied to one workgroup. – The workgroup can be changed. A workgroup can be used by more than one project. – Even by more than one developer. 10

11. Packages “Release Packages are the containers used to deliver software.” Packages are known to the lpr. Resources are chosen for inclusion in a package by workgroup. 11

12. Packages: Things to Consider You can have multiple workgroups per package. It’s very complicated to have a single workgroup on multiple packages. – Technically, it’s possible. – If it’s a single workgroup on multiple packages at the same time, it’s practically unmanageable. 12

13. Update Groups An update group is a bundling of one or more packages for installation. – You cannot install “part of” a package. 13

14. Options and Best Practices

15. Option 1: The OneFer Basis The OneFer option is to have a single workgroup, period*. Pros: Prevents “fragmentation”, proliferation of workgroups everywhere. Cons: Makes it nearly impossible to manage packages if you have more than one “thing” in development at one time. 15

16. Option 2: The OnePer Basis The OnePer option is to have each resource in its own workgroup. Pros: Follows a resource throughout its lifespan. Cons: Any time you work on something requiring more than one resource, you have to create multiple projects to do so. – Adds risk to software delivery. 16

17. Option 3: Workflow-Based The Workflow-Based option is to a create workgroup for each “workflow”. Pros: Keeps resources that “go together” together, and follows those groupings throughout their history. Cons: Does not play well with paradigms where development focuses on “reusable” code. 17

18. Option 4: Project-Based The Project-Based option is to create a workgroup for each conceptual development project. Pros: Groups resources that will need to be delivered together. Cons: Does not follow resources through their history. 18

19. Finding Custom Impact

20. Story Time: Hidden Impact How many people here have had things break after patching—things that did not appear on the custom impact report? 20

21. CIR: What Is Included? CIR = Custom Impact Report It includes resources only in these conditions: – The impact is direct – The custom version is the most current version The resource must meet both of these criteria. 21

22. What Constitutes Direct Impact? What is being delivered in the update? – Was that resource modified directly by you? OR – Is that resource marked as the original process name on any of your custom resources? Note that you can have only one original process name on any given custom resource. Not all resources can have an original process name. 22

23. What is “Most Recently Installed”? Was the version on the custom package installed into (or released from) the environment in which the CIR is being run after the last time it was installed on an Ellucian update? 23

24. CIR: What is Excluded? Anything of “secondary” impact – Example: That Ellucian subroutine you have 5 custom web forms relying on. Anything you didn’t (have to) update the last time Ellucian redelivered that related resource. – Solution: Make sure you at least reinstall the custom process if you still need it, even if you don’t need to modify it. 24

25. Finding Secondary Impact Review the Items list. Import relevant resources into Colleague Studio. Use the Show References function on each resource. – Right-click the resource. – Choose the Studio sub-menu. – Click Show References. 25

26. Long-Term Improvements Promote IDEA 25879 – Include Secondary Impact in Custom Impact Report 26

27. Summary Standardize custom management across all developers. –Choose a strategy for grouping resources under projects, workgroups, package, and update groups. –Choose a consistent naming convention. Plan thorough custom impact analysis as part of your standard patch procedures. –Don’t rely solely on custom impact reports. 27

28. Questions & Answers 28

29. Thank You! Katie Morgan katie.morgan@pacificu.edu Please complete the online session evaluation form Session ID 29