ALM and CI - are you into it?

[Susan Duncan]

Hi everyone,

As many of you will know I'm a strong proponent of all things ALM
(application lifecycle management) and CI (continuous integration). I
recently saw some of the latest statistics from the new member survey
for this group. Did you know that

When asked what CI server you use -
20% answered - 'what's continuous integration'
and another 40% 'we don't have any plans'

When asked what ALM tooling you use -
22% answered 'what's an ALM tool'
and another 39% 'we don't intend to use one'

Is that really true - some of you have no SCM, requirements planning,
defect systems, change management, CI tools.......? Or is it the terms
you don't like? Now, this is only a small sample, only over a short time
frame and I know many of you are using many tools, but ...

As one of the guardians of Hudson SCM, Maven, Ant , Testing and Team
Productivity Center (TPC) and more in JDeveloper I'd love to hear from
you. What do you like, what don't you like? What are you using, why or
why not?

I can guess at some of your comments - no support for Maven and ADF yet,
no Git support yet. but what else? What is stopping you from using TPC
or Hudson? If you are using them - what is the best feature, what is
missing? You would/wouldn't go near Git - why (not)?

I've just returned from EclipseCon where there was a whole track
dedicated to ALM and to Hudson. I'm excited and motivated to get even
more feedback and feature ideas from you JDeveloper users. So drop me a
line, here or privately and give me your thoughts and ideas

rgds

susanr

[Jan Vervecken]

Thanks Susan.

Can you point to a concrete example of continuous integration (CI)
using Hudson for a (Fusion stack) ADF application (using ADF Faces,
ADF Model, ADF Business Components)?
So, an example ADF application that includes tests (of any kind) that
can be run (using Ant or Maven) using Hudson.

many thanks
Jan Vervecken

[Andreas K]

Hi Susan,

from time2time I stick into OTPC because I really think it is a nice JDev add-on. 

My observations are the following

PROs

[OTPC-1] Saving the jdev project context according to some workitem! Very usefull feature 
[OTPC-2] Integration of different issue management systems and Task repository

CONS

[OTPC-3] Calling the Test Server Page (<host>:<port>/otpc) you just get a simple message “Oracle Team Productivity Center”. No Version information build no, active connectors, etc.....!!! ER: I would expect that OTPC Modules itself are built with Hudson, Maven to prove its capabilities, stability and best practices. The lease recent tested version by me (11.1.2.1) does still not look enterprise production ready!! Sorry. It looks like a (not production ready) beta version…

[OTPC-4] Do I really have to create all the users into the OTPC repository by hand? Can’t I connect to an LDAP-Server? This also looks not enterprise production ready. Sorry. ER: Connect to LDAP server and map user/groups to OTPC roles.

QUESTION

Does Oracle use OTPC on e.g. Fusion Apps Development or maybe smaller projects? What are the experiences? Thx.
Do other members of this group using OTPC on a daily basis for ADF/WebCenter/SOA projects?

You can read more about it my experiences regarding ALM with TPC/TPC-Hudson-Plugin

http://multikoop.blogspot.de/2009/12/oracle-team-productivity-center-otpc.html
http://multikoop.blogspot.de/2011/05/alm-with-oracle-team-productivity.html
http://multikoop.blogspot.de/2011/10/upgrade-oracle-team-productivity-center.html

BTW: Sure we are using ALM and CI tooling. Currently our env/toolset consists of: JDev, Hudson (+some nice plugins), SVN/TortoiseSVN, Shell scripts, Ant-scripts, ojdeploy, WLST-scripts running JUnit tests, pl/Sql tests, selenium tests, scripting SQL-Updates, deploying ADF apps on test server, generating docs, packing source distro, release distro (full, patch, separated by db,app,reporting). Just to mention a few CI steps..

Cheers
Andreas

[John Flack]

In the past, we've been a small group of "cowboy coders".  Each of us was working on different projects, with only a little bit of interfacing between us.  We were even using different languages - I and two other developers have been coding with JDeveloper/ADF for several years, but others were working in Oracle Forms and PL/SQL.  Deployment and testing was uncontrolled - not a mess because if something screwed up, we knew who did it.  But uncontrolled - when the developer and the users of his/her application were convinced it was ready for production, the developer had full access to deploy to production.  A bit more wild and woolly (CI? ALM? who needs that?) than most people are used to, but it worked for us.

I'm proud to say that we've been good enough at what we do, that our major client has asked us (and given us more money) to do more.  As a result, our small team of developers has grown, and we're probably going to add a few more people yet.  But to whom more is given, more is expected.  I've just been made sheriff of this wild and woolly group of developers - my first supervisory position in years (and I swore I'd never do it again) - before now I was just the lead developer and system architect, kind of a first among equals, with no real authority.  One of my mandates from my boss is to work with our new Configuration Management and Quality Assurance team to clean up our act.  The first thing our new CM guy did was install Hudson, and work to get an automated deployment of one of our ADF applications to work.  Took some doing - some of the libraries it used were not in the project folder, so the project couldn't be compiled from just anybody's working copy from Subversion.

A lot of words to say - we are just at the beginning, and have a lot to learn.

[Jean-Marc Desvaux]

Thanks John for this very nice post. A pleasure to read.

Dear Susan,

We still have "cowboy coders" like John had before, each working on a separate project most of the time and very rarely on the same. We do use Subversion which we believe is a necessity even for a single developer.

The team will not grow soon and for a small team like ours it is a bit hard to find CI & ALM attractive at its current state in JDev/ADF/WLS. It seems you still have to fight a lot to get them work for you nicely.

Our state allows us to wait for the possible benefits of further simplification that can be expected in future releases... ;O)

Jean-Marc

[Chad Thompson]

On Friday, March 30, 2012 at 5:12 PM, Susan Duncan wrote:

Is that really true - some of you have no SCM, requirements planning,

defect systems, change management, CI tools.......? Or is it the terms

you don't like? Now, this is only a small sample, only over a short time

frame and I know many of you are using many tools, but ...

I'm someone who has experienced a variety of environments at client sites and can share a few general observations regarding the use of CI, etc.

1)  I've worked with a number of teams that are smaller groups, or groups that do not necessarily see themselves as a 'development' group, rather considering themselves to be 'support' for various purchased Oracle products (from E-Business Suite to Identity, Fusion Middleware, etc.)  In these instances, the barrier is largely cultural - there is not time invested in learning development tools or setting up a decent development environment.  

"Well, Bob made a few Java classes, so we keep them in a shared directory on the ____ server."

2)  CI tools like Hudson are also often wrongly thought to be something that you only use if you are using 'agile' processes.  I've seen this before - "Well, we only need to do a build for QA a day prior to testing, so…."  (My response:  "How do you actually know your build works?")

[NOTE:  To anyone not using Hudson as a proper "CI" tool - the ability of Hudson to run build and deployment scripts through a web interface will provide immediate payoff.  Pressing the 'build now' button versus having to worry about shared server accounts, etc. will save time in headache in less than a day.]

3)  In many cases, the reason for not adopting a new tool is simply the natural resistance people have to changing their own personal workflows.  That is, the most efficient process to you is often the one that you know.

4)  … and along with the workflow issues, there can also be resistance to (depending on the type of project) introducing JDeveloper to a team that heavily invested in an Eclipse-based infrastructure, or taking the approach that "We only use JDeveloper for ____ type of projects, and Eclipse for others."  It's difficult to adopt something like OTPC as a workflow when JDeveloper is a 'sometimes' type of tool.

 

As one of the guardians of Hudson SCM, Maven, Ant , Testing and Team

Productivity Center (TPC) and more in JDeveloper I'd love to hear from

you. What do you like, what don't you like? What are you using, why or

why not?

If I were to make a few suggestions:

1)  In terms of CI tools, it would be very handy if Oracle would package "ojdeploy" in a way that I could include it in ANT scripts or Maven POMs without having to deal with JDeveloper itself.

2)  OTPC would likely get better pickup if there were also Eclipse plugins available.  (The great thing about OTPC is the connector architecture that allows you to 'fit in' to environments using JIRA, Bugzilla, etc. - but in terms of personal workflow, having something that developers could consistently use from the IDE rather than opening up the separate web browser window, etc.)

3)  I'd also like to see OTPC have "project" connectors to something other that MS Project, like Atalissan GreenHopper or VersionOne for agile teams.  (I realize this is a hard market to hit and/or justify the development cost.)

 

I can guess at some of your comments - no support for Maven and ADF yet,

no Git support yet. but what else? What is stopping you from using TPC

or Hudson? If you are using them - what is the best feature, what is

missing? You would/wouldn't go near Git - why (not)?

I was initially hesitant to "Git", but have to admit that I've warmed up to Git - and would appreciate Git integration.  (Primarily because I've settled on GitHub for storing code examples and items to share.)

 

Thanks for all of your work, and a great thread, Susan!

-- 
Chad Thompson 
chad_t...@mac.com

[Susan Duncan]

Hi Andreas,

Thanks for all this great info. A couple of responses inline

keep the info coming!

rgds

susan

On 31/03/2012 10:16, Andreas K wrote:
>
> Hi Susan,
>
> from time2time I stick into OTPC because I really think it is a nice
> JDev add-on.
>
> My observations are the following
>
> PROs
>
> [OTPC-1] Saving the jdev project context according to some workitem!
> Very usefull feature
> [OTPC-2] Integration of different issue management systems and Task
> repository
>
> CONS
>
> [OTPC-3] Calling the Test Server Page (<host>:<port>/otpc) you just

> get a simple message �Oracle Team Productivity Center�. No Version

> information build no, active connectors, etc.....!!! ER: I would
> expect that OTPC Modules itself are built with Hudson, Maven to prove
> its capabilities, stability and best practices. The lease recent
> tested version by me (11.1.2.1) does still not look enterprise
> production ready!! Sorry. It looks like a (not production ready) beta

> version�
>
definitely an ER for more info from the server. But beta? I would have
to question you there

>
> [OTPC-4] Do I really have to create all the users into the OTPC

> repository by hand? Can�t I connect to an LDAP-Server? This also looks

> not enterprise production ready. Sorry. ER: Connect to LDAP server and
> map user/groups to OTPC roles.
>

Coming in a future release

>
> QUESTION
>
> Does Oracle use OTPC on e.g. Fusion Apps Development or maybe smaller
> projects? What are the experiences? Thx.
>

I am collecting that type of information at the moment and will
endeavour to get some info out.

>
> Do other members of this group using OTPC on a daily basis for
> ADF/WebCenter/SOA projects?
>
> You can read more about it my experiences regarding ALM with
> TPC/TPC-Hudson-Plugin
>
> http://multikoop.blogspot.de/2009/12/oracle-team-productivity-center-otpc.html
> http://multikoop.blogspot.de/2011/05/alm-with-oracle-team-productivity.html
> http://multikoop.blogspot.de/2011/10/upgrade-oracle-team-productivity-center.html
>
> BTW: Sure we are using ALM and CI tooling. Currently our env/toolset
> consists of: JDev, Hudson (+some nice plugins), SVN/TortoiseSVN, Shell
> scripts, Ant-scripts, ojdeploy, WLST-scripts running JUnit tests,
> pl/Sql tests, selenium tests, scripting SQL-Updates, deploying ADF
> apps on test server, generating docs, packing source distro, release
> distro (full, patch, separated by db,app,reporting). Just to mention a
> few CI steps..
>

I'm interested in which Hudson plugins you are using too?
>
> Cheers
> Andreas
>
>

[Susan Duncan]

John,

Firstly congratulations! On taking on that type of role again and especially on implementing Hudson. I'd like to here more about how you are using it and what plugins you might be considering. Are you trying to apply the 'nirvana' of CI (no build longer than 10 minutes, commit and nightly builds.....) or using what always to me seems the more practical approach of 'build frequently as appropriate'?

What type of jobs are you moving into Hudson? Java, ADF, DB? build, deploy, Ant, Maven. What IDE/development style? Have you considered TPC or other ALM pieces (JIRA....)  ..... we can certainly catch up in person at ODTUG this year too.

rgds

susan

--
You received this message because you are subscribed to the ADF Enterprise Methodology Group (http://groups.google.com/group/adf-methodology). To unsubscribe send email to adf-methodolo...@googlegroups.com
 
All content to the ADF EMG lies under the Creative Commons Attribution 3.0 Unported License (http://creativecommons.org/licenses/by/3.0/). Any content sourced must be attributed back to the ADF EMG with a link to the Google Group (http://groups.google.com/group/adf-methodology).

[Susan Duncan]

Tell me more - " Took some doing - some of the libraries it used were not in the project folder, so the project couldn't be compiled from just anybody's working copy from Subversion."

rgds

susan



On 02/04/2012 06:03, John Flack wrote:

--

[John Flack]

Thanks for the congrats - I'm asking, "Did I ever say, 'This application development gig is great, but what I really want to do is direct.' Did I?"

We have been using source control, first IBM Rational ClearCase LT, but now Subversion, for several years.  Even getting that implemented involved breaking some old habits, like "before you make changes, make a copy of the file with a slightly different name".  I still see multiple copies of the same file in source control sometimes, but not from the developers any more - they get it - but from one of our web designers (I don't supervise them - they're available on an "as needed" basis).

We'll be doing a slow transition from what we've been doing to the more controlled way of working. Since we still have only one or two developers on each small project, there is no such thing as a single build.  Each project is separate, with few dependencies.  The one exception to the rule is the COMMON project.  Most of the COMMON project today is database oriented - shared tables and PL/SQL, but we are writing a set of shared ADF BC base classes, and a set of ADF Faces templates, and a shared ADF Faces skin that we'll deploy as ADF Libraries.  All the other projects will depend on COMMON.

The plan is to do builds as needed, with no scheduled builds.  However, a new build of COMMON will trigger new builds of everything else.  Where before, any developer could deploy to a test server or even to production, we will transition to make deployment the configuration manager's job, and not allow developers to do it any more.  Deployment will be from a build done on the build server, never from a build done on the developer's workstation by JDeveloper as we do now.

Which leads to your question.  If you build with JDeveloper on your own workstation, you can reference things that are not in your working copy from Subversion.  For instance, we are using BIRT and the jsf4birt JSF component library for reporting.  That means that your ADF project (the .jpr file) must reference the BIRT libraries - but those libraries need not be in the project folder.  But if the libraries aren't in your project folder, when the build server updates its working copy of your project, it doesn't get a copy of the libraries.  Therefore, it can't build your project even though JDeveloper on the developer's workstation can.  During our first experiment with an automated build of one of our projects, we discovered that the developer had done exactly that - put the BIRT libraries in a folder that wasn't in her working copy.  One solution is to put the libraries in the ViewController project's WEB-INF/lib folder, and add them to source control, which is what we did.  Another solution may be to put the libraries in the same relative location on both the developer's workstation and the build server.

[Andreas Koop]

@Susan

Thanks for the information.

Well, to be honested most of the CI steps are done from a master build script so we are not too tightly coupled with Hudson.

One of the most useful/powerful plugins for Hudson is the log-parser Plugin. It is easy to set up and really flexible in order to identify a broken build because of some unexpected. Further we use PMD/CPD for static code analysis. + a plugin to identifiy //TODO // FIXME etc. source code.

Andreas.

[Jan Vervecken]

hi Susan

Any suggestions for my previous question?

"Can you point to a concrete example of continuous integration (CI)
using Hudson for a (Fusion stack) ADF application (using ADF Faces,
ADF Model, ADF Business Components)?
So, an example ADF application that includes tests (of any kind) that
can be run (using Ant or Maven) using Hudson."

many thanks
Jan Vervecken

[Susan Duncan]

I don't have a running example that I can point to. But I'm working on it!

rgds

susan