Introduction to RTC Source Control for IBM i Users

One of the most common questions and confusion about RTC from new users is how the Source Control Management(SCM) works and where is the code base of my IBM i code in RTC.  Today IBM i developers are used to looking in libraries to find their source, but with RTC that is no longer the case as the official source is stored in the RTC database.  Lets walk through a typical scenario to understand how this all fits together.

• The team as a first and one time step takes your current source residing in your IBM i Libraries and using the tooling in Rational Developer for Power Systems converts it into 1 or many IBM i Projects.  An IBM i Project is a collection of the source in an Eclipse project style which mimics the structure of an IBM i Library.  Learn more about IBM i Projects by watching this video. By using an Eclipse project style to store your source there is no difference between the way this source is stored on your local machine as compared to a Java project, so all the powerful SCM capabilities in RTC apply to IBM i Projects as well like History, Annotate, Suspend, etc.  Once the projects are defined they are then shared with a stream.  At this point your official source code base is stored in the RTC Database not in any IBM i Libraries.  This is why you can have the RTC server running on any platform, it doesn’t have to be running on IBM i.
• As a developer I create a Repository Workspace, connected to the stream we shared the projects with in the previous step, in which I load IBM i Projects from to my local workstation.
• I work on the development of my IBM i source and use the capabilities in Rational Developer for Power Systems Software.  When I am ready to test my changes I use the push(load)/compile capabilities in Rational Developer for Power Systems or Personal Builds in Rational Team Concert to load and build(compile) the source in my own personal libraries.  When I am confident with my changes I deliver them to the stream. Notice the developer is not using the green screen or an emulator to modify the code, they are using Rational Developer for Power Systems Software for making all source code changes.
• A team build is run based on a schedule or someone requests a build (using one of the IBM i build definitions in RTC) that will load the source from the RTC Database to IBM i Libraries defined in the build definition and then compile the source.

To recap the official code base of your applications is stored in the RTC database, developers can use there own personal libraries to compile there changes, and official team builds are the mechanism to load the source from the RTC database to the IBM i Libraries and then compile(build) the application.  To learn more about the SCM capabilities in the RTC Eclipse client read the help topic on just that.

What’s new in RTC 4.0 from an IBM i Perspective

During the development for RTC 4.0 we remember a customer asking us what happened to RTC for IBM i?  We all were puzzled by the question as RTC 4.0 has the most new features for IBM i customers since the initial release of RTC on IBM i.  In a future blog post we will detail how to navigate the plan items for future releases to tell what is for IBM i or not to avoid this type of question/confusion.  We like to think of RTC 4.0 as the release where we dramatically closed the gap between z/OS and IBM i.  In previous releases we had for example Promotion capabilities and work item packaging for z/OS but not for IBM i.  With the 4.0 release we have closed the gap considerably and now have for IBM i along with z/OS the main three functionalities of: Dependency Build, Promotion, and Deployment.

Dependency Build
In past releases (RTC 2.0 and newer) we introduced the IBM i Build Specification build which is a dependency build, but did timestamp checking to determine everything that needed to be built then based on what was built determined what else needed to be rebuilt.  In RTC 4.0 we introduced the IBM i Dependency Build Definition template which works the same way the old Dependency Build template did for z/OS (now renamed z/OS Dependency Build).  No longer do we do timestamp checking but instead look directly at what has changed and the database of dependencies that have been scanned to determine what to build, which will result in much faster builds for all of you!  In addition we have added new scanners to look for dependencies in DDS, CL, and PF files.  New for both z/OS and IBM i is a new build report that is much enhanced from the previous build report in the IBM i Build Specification builds.  You will be able to see everything that was built, with the reason why it was built, and more.  To learn more about the new IBM i Dependency Build go to the Information Center, read an article, and/or watch a video on it.

Promotion
In previous releases you had to manually promote your source from one stream to another and then run builds or package/deploy to get the built binaries in that new environment.  It is now possible to create Promotion definitions to promote from one level to another.  These promotion definitions will promote your source and potentially your binaries to the new level in your environment.  As we have already gotten questions related to the Promotion capabilities we want to highlight some specifics.  Promotion definitions run on the same machine the Source build ran on, this means when you think of promoting binaries they are all on the same machine as the build.  If you want the binaries on a different machine you will want to refer to the Deployment capabilities after.  Robin Yehle has a great blog post talking about this from a z/OS perspective, but all the same logistics apply to IBM i.

Deployment
In previous releases we had sequential packaging and deployment, where the packages deployed had to be deployed in the sequence the packages were created. It is now possible to deploy packages in a non-sequential order by selecting the package to deploy. You can also deploy a package multiple times. New for IBM i is the introduction of the work-item based packaging feature. This includes packaging of one or more work items, thereby packaging the built output objects from the change sets associated with the work items. In addition, the UI for packaging and deployment has been completely changed. The ship list and restore mapping files can be now created in a new UI for the IBM i package definitions. Objects can be added manually to your ship list or a query can be run to find outputs from the Enterprise Dependency Build (IBM i)  build definitions. You can map libraries to the libraries to use during deployment in the package and deployment definitions. Lastly we still provide backwards compatibility for 3.0 and 3.0.1 versions. Package and Deployment definitions using 3.0.1 format can be successfully run using the 4.0 server and build system toolkit. To learn more about the new Deployment capability go to the Information Center.

Those are the highlights of the new functionality available specifically to IBM i users, but many more improvements went into RTC 4.0.  For a full list see the New and Noteworthy.