Transcript Managing Colleague Custom Software

Managing
Colleague
Custom Software
Presented by:
Katie Morgan
Pacific University
August, 2014
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.
Thank you for your cooperation!
2
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
Agenda
• The “layers” of custom resource
“groupings”
• Various approaches to grouping custom
resources
• How to find all custom resources impacted
by Ellucian updates
4
Projects, workgroups,
and packages!
Oh, My!
“Layers” Overview
•
•
•
•
Projects
Workgroups
Packages
Update Groups
6
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
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
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
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
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
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
Update Groups
• An update group is a bundling of one or more
packages for installation.
– You cannot install “part of” a package.
13
Options and Best
Practices
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
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
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
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
Finding Custom Impact
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
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
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
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
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
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
Long-Term Improvements
• Promote IDEA 25879 – Include Secondary
Impact in Custom Impact Report
26
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
Questions & Answers
28
Thank You!
Katie Morgan
[email protected]
Please complete the online session evaluation form
Session ID
29