Toward a new model of Natural software development: Natclipse and version control • Christopher Cain • email@example.com • 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?
Pages to are hidden for
"Toward a new model of Natural software development"Please download to view full document