Toward a new model of Natural software development by byt34827

VIEWS: 13 PAGES: 21

									     Toward a new model of Natural
    software development: Natclipse
          and version control
•   Christopher Cain
•   ccain@austin.utexas.edu
•   Senior Systems Analyst
•   ITS – Applications, The University of Texas
    at Austin
                 UT Austin
• Our goal is a cross-platform cross-language
  unified development process with all of our
  projects in the same Integrated Development
  Environment (IDE). I’ll discuss our plans to
  realize this goal, our experiences so far, and
  explore the implications of this approach.
                   Goals
• Introduce version control
• Introduce a new state-of-the-art Integrated
  Development Environment
• Introduce a central deployment mechanism
                   Plan
• Version control: Subversion
• IDE: Eclipse and Natclipse
• Deployment tool: Lifecycle Manager
UT Austin Developer Community
• Several hundred campus developers
• Central IT department as well as teams of
  varying size distributed around campus in the
  many colleges and departments
• Some teams work almost entirely in Natural,
  others don’t use it at all (Java, PHP, Python,
  Ruby on Rails, etc) and others are a mix
• Administrative systems are mostly Natural-
  based, academic systems mostly not
• We have a training program for Natural
  developers
     History of Natclipse at UT
• Idea at UT ~4 years ago premised on use of a
  standard IDE and access to version control
• agreement to collaborative development effort
  with SAG
• discovery of Innowake’s product
• evaluation of SAG version
 Natclipse vs. Natural for Eclipse
• Natural for Eclipse is a re-branded version of
  Natclipse that uses the Natural Development
  Server on the backend
• Natural for Eclipse did not work very well when
  we tried it ~20 months ago
• We hear that others are still having similar
  experiences
• This licensing arrangement will end in February
  and SAG will develop their own version of this
  product
 Our experience led us to Innowake
• Great support, keen interest in our business
  and in improving their product
• Favorable licensing terms, didn’t have to buy
  in to a big package
    Natclipse vs. a 3270 emulator
• The 3270 emulator gives us remote access to the Natural
  environment running on the mainframe. We have at our
  disposal only the tools that we’ve license from SAG or
  built ourselves. We open a single module in the editor and
  then modify it using line commands; anyone else can open
  the same module and overwrite our changes with no
  indication it has happened.
• Natclipse allows us to pull all of our Natural code onto the
  desktop, normalized into plain text files. With our Natural
  code on the desktop we are able to tap into many of the
  desktop tools and techniques of the modern software
  developer, even if they weren’t created specifically to work
  with Natural.
           Natclipse vs. SPoD
• SPoD operates on the same principle as the 3270
  emulator, it offers a window onto the mainframe.
  It is a simple text editor with some updated
  features and Windows GUI integration.
• Natclipse is part of the Eclipse Integrated
  Development Environment; it is much more
  than a text editor as it offers many features to
  transform and analyze code. Natural code is still
  executed and tested on the mainframe.
                    Eclipse
• A proven IDE from a strong corporate backer
  (IBM)
• Great cross-platform performance
• Free!
• Open source, can be extended or customized as
  necessary
• Support for many different languages
• Built in support for version control
• Plug-in support for connections to standard
  issue-tracking systems like Jira, Bugzilla, Trac
              Version control
• It’s a proven, standard industry approach
• The auditors require it
• Version control addresses questions we are
  currently unable to answer such as:
  – How long has this bug been in production?
  – When was a particular part of the code written?
  – What were the last set of changes made to a module
    or system? Full history of changes?
  – How do I make big system changes without
    interfering with ongoing work? (branching)
 Version control for Natural code
• Plain text is a useful format, easy to perform a DIFF
  and merge the results
• We can keep our documentation and web scripts with
  our Natural code
• Using version control allows developers to be more
  productive and make modifications with confidence
• Problem: some Natural libraries are in bad shape and
  not ready to be version controlled – Natclipse can help
  us compare libraries and merge differences
• The definitive copy of source code lives in a
  Subversion repository, and our mainframe libraries
  are just deployment environments
            Natclipse demo
• Project structure
• Keyboard shortcuts, customizable perspective
• Dependency view, outline view
• Code completion, object hyperlinks, use DDM
  to create view
• Templates, ToDos (date in comment),
  compare with history
    Implementation (client/server
           architecture)
• Natclipse wasn’t set up for a large distributed
  environment like the one at UT, but
  Innowake worked with us to secure the
  communication channel to the central server
• There is some Natural code to deploy, which
  Innowake helped us to integrate with our
  home-grown security model
• Some local work to do:
  startup/shutdown/monitoring scripts
  Implementation of version control
• We learned a number of things about our
  version control service in our initial Natclipse
  evaluation:
  – Version control should be free, it’s bad policy
    for ITS to charge folks to use it when we
    advocate it as a best practice
  – Repositories should be easy to acquire and
    administer by developers, and not require the
    intervention of a central administrator
            Deployment goals
• We will be able to deploy a particular version of
  our code base directly from version control to
  the target machine & environment
• We’ll have a record of exactly which code was
  deployed, by whom, at what time
• This model will work just as well for Natural as
  it will for java, etc.
• Innowake offers a product that accomplishes
  these goals called the Lifecycle Manager, which
  they will present at a session tomorrow.
            Strategic implications
• We can train our developers in a single toolset and methodology,
  which can easily be applied to all of their projects whether
  Natural, Java, Python, etc.
• We can hire developers already familiar with desktop tools and get
  them working in Natural with less time spent in training.
• We can work on our Natural code without an active mainframe
  connection.
• We can allow others to work on our code even if they are not
  authorized to deploy or execute it.
• Desktop scripting – with our Natural code in plain text files we can
  write scripts for code transformation/generation, plugging into
  existing developer knowledge using desktop languages for which
  information is readily available
               Hurdles to adoption
• Our decentralized environment – a few large development shops and a lot
  of smaller teams scattered across departments & colleges. There is no
  one administrator who can simply make a decision that developers across
  campus will adhere to.
• Many UT developers who work with Natural and their managers have
  never used version control. There is a perception that if they have gotten
  by for this long without it that they can continue to do so.
• Community resistance to change – there is always a cost to learning a
  new set of tools and our technical community is very conservative.
• To get the most benefit out of Natclipse, all of the developers on a project
  should be using version control. Without management support a single
  recalcitrant developer can reduce the teams’ effective use of these tools.
• Our System library is a giant mess, due to the nature of our homegrown
  security model.
       Overcoming the hurdles
• We’re introducing it on smaller teams and
  putting it in the hands of early adopters.
• We’re providing training with a goal of seeding
  knowledge of this toolset around campus, to
  provide future users with local experts.
• Right now we have 40 folks using it, out of 200+
  Natural developers
• We think it is the best tool available but we are
  not forcing it on anyone or removing their
  existing tools
Questions?

								
To top