Once upon a time,
not so long ago, there lived a Developer who worked for a software firm called
Chaotic Systems. The process of software development in this firm was
error-prone and, in many ways, sub-optimal. The Developer didn’t realize it
then; being a newcomer, he was inclined to attribute mistakes to his own
carelessness rather than think about whether the systems he worked with
helped him do his work in a manner that was less error-prone, and whether the
tools he used enhanced his productivity.
A picture from
they were developing was COM based, and to set the right working environment
they used to copy the binaries ( .dll and .ocx files ) of all dependent
components from the build machine to their local machines and ‘register’ them.
The project was a large one – they had a number of inter-dependent components –
and typically all of these had to be taken together, because the
dependencies were not always clear ( they had to be manually extracted by
looking into the project definition of each component ). There was a batch
script to perform this task (of un-registering the old components, copying the
new and registering them ), so even though this had to be triggered manually (
outside the IDE ) this was not much of a problem.
Why DTR ? Why not Perforce or ClearCase…?. The server of SCM tool was located in
their head office, and hence the sync of sources was extremely slow. And he
always had to do double maintenance for the fixes he made in the code lines (
branches ) of earlier releases. ,
he only needs to ‘Create a Project’. The tasks typically needed +before +
creating a project – like synchronizing sources from the repository, getting the
archives ( binaries ) of dependent Development Components from somewhere else –
is done automatically by the SAP NetWeaver Developer Studio. It contacts the
right systems in the landscape to get the sources and archives. The Developer
also sees that the archives of only dependent Development Components are
fetched. From the documentation he finds out that this is possible because
dependencies between Development Components are declared explicitly, as defined
After making some
changes, the Developer triggers a local build of his Development Component,
using the SAP NetWeaver Developer Studio. He then notices that a special
component – a
– is available on his machine, and that
performs the local build of his component.
the successful local build, the Developer does a ‘check-in’, which checks-in the
changes into the
of his “development” code line .
After a check-in, the SAP NetWeaver Developer Studio asks him if he wants to
his changes. He chooses to activate, and this triggers a build of
the Development Component on the central
Component Build Server
( CBS ).
He learns that in the background, a lot of things happen at this stage : if the
build is successful, the CBS stores the newly built archives of this Development
Component into its archive pool, and also triggers an “integrate” of the change
of the code line by sending a request to the
Why DTR ? Why not Perforce or ClearCase…?( DTR ), where the sources are located.
between inactive and active makes the Developer realize that he can safely
check-in his intermediate changes and share his partly complete work with other
developers in his team. This will not cause any build failures, since sources
that lie in the inactive workspace are not built centrally unless a change that
was checked-in to this workspace is explicitly activated.
activation, he informs his colleague – who is waiting for this fix – that his
modification is now available. That colleague syncs the Development Components
he depends on, and gets the newly built archive ( containing the fix ) from the
archive pool of CBS. So the colleague does not have to wait overnight for a
binary ( archive ) containing a fix he needs.
The time soon
comes when this Developer has to create a new Development Component of a
specific type – Java. While creating it from the SAP NetWeaver Developer
Studio, he wonders if he will have to write some build scripts to get this
Development Component built. He soon realizes that this is not necessary : the
Build Plug-in that builds Development Components of type Java is automatically
downloaded to his machine when he chooses to create a new Development Component
of type Java.
When he adds a
class to this new Java project, he gets a popup asking him if he would like to
add this file to source control ( into DTR ). He chooses ‘Yes’, and that results
in the class getting added to an
in DTR. This prevents build
errors occurring due to missing files caused by users who forget to add new
files into source control.
check-in and activation of this new Development Component into the “development”
code line, he decides to consolidate his change into the “consolidation” code
line. To do this he chooses to
his activity, from the SAP
NetWeaver Developer Studio. This places the activity into a queue, and an
administrator monitoring this central queue imports it into the inactive
workspace of the “consolidation” code line using the
( CMS ). If the import is successful, the CMS triggers the
activation of this change in the “consolidation” code line, followed by the
deployment – through the
Software Deployment Manager
( SDM ) – of the
Development Component into a central test system.
After some days,
the Developer gets a mail stating that his Development Component is “broken” –
that is, the build of this Development Component ( which was automatically
triggered by CBS because an interface it used from another Development Component
had changed ) had failed. Since someone else had modified an interface he used
in his code, he now has to adjust his code to the modified interface. Using the
SAP NetWeaver Developer Studio, he syncs this Development Component and all
dependent Development Components. This results in the download of the latest
archives of the dependent Development Components to his local machine. He sees
that a Development Component he uses has modified the signature of a method, so
he makes the change to use the new signature, checks-in his changes and
activates it. The activation succeeds, and his Development Component is no
longer in a “broken” state.
later, he begins work on a new release. For this, his Quality Manager informs
him that he should use a new Development Configuration ( “Dev 2.0” ) . Using the
SAP NetWeaver Developer Studio, he imports this new Development Configuration
and begins work ( Behind the scenes, the SAP NetWeaver Developer Studio +could
+be connected to a completely different set of systems – DTR, CBS etc – for
this new release, but for the Developer this is transparent ). After a while,
when he has to make a fix in the older release, he simply opens the other
Development Configuration ( “Dev 1.0” ), selects the appropriate Development
Component, creates a project and makes his change. The switch in context takes
nothing more than a few clicks in the SAP NetWeaver Developer Studio. He also
sees that since DTR supports integration of changes in both directions, he does not
have to redo this change in the new release – it will automatically get
integrated, and if it conflicts with a change he has made in the new release, he
will have to merge the two.
Developer, happy with the enhancement in productivity JDI has brought in,
ponders over the fact that things have really changed since times in the past.
The infrastructure has evolved, and that helps him work better today, making
fewer mistakes and spending lesser time on house-keeping tasks. ( Not all
developers are as reflective as our Developer here – most of them do not notice
the huge infrastructure backbone which aids their work in the background. This
probably speaks highly of the infrastructure – if nobody notices it, doesn’t it
mean it is doing its job well ? ).
the bottom line
What does this
story of evolution mean for our customers ? Apart from the obvious advantage
that the quality of applications they buy from SAP would be a few notches higher
thanks to all this infrastructure support, our customers also will get this full
fledged infrastructure to make use of. While this is clearly an advantage for
big customers who have large teams that customize the products they buy, an
infrastructure of such a scale seems like an overkill for smaller customers. The
overhead involved in setting up and maintaining this complicated landscape is
something these small customers would clearly like to avoid.
this by supporting multiple
, based on the requirements of
customers and on their existing infrastructure. From using only DTR to version
their files in a small project, to using the complete infrastructure to manage
their landscape, these well documented scenarios address the requirements of
customers in different segments. Further, there are migration paths available
to move from one scenario to another.
Finally, a few
words about naming. Although the name “Java Development Infrastructure” conveys
that the infrastructure supports development of applications based on Java, this
notion is not wholly correct. Development using JDI relies on the SAP Component
Model, which is a model independent of technology. Today, the types of
Components that are being built are based on Java; tomorrow they could be based
on, for example, .Net, or any other technology.