When we are automating our builds and testing with CI, one thing that we really want is deterministic builds.  Said another way, we want to be able to run a particular job again and get the same result.  SNAPSHOTs introduce an element of non-determinism to the build – artifacts with SNAPSHOT versions will resolve to the latest snapshot version that happens to be available when the build is run, and they all have the same ‘version’ – snapshot versions look like ‘2.1.2-SNAPSHOT’.

So this means that SNAPSHOTs and CI do not play well together.

But there is a relatively simple way to get the behavior we want without using SNAPSHOTs.  To be clear on that, the behavior we want is this:

• whenever we do a build, we want to pick up the latest available version of the (in development) dependencies,
• we want to know which particular version/build of a dependency we actually used in any given build,
• we want to be able to repeat the build and get the same outcome.

For the purpose of discussion, let’s assume our source code is in git, we build our projects with Maven, perform CI on a Hudson server, and we publish our artifacts to Artifactory.

So let’s consider two projects that are both under active development at the same time – i.e. they are both changing day to day:

• super-common, version 2.0.1– this contains common code that is used by a number of applications,
• super-webapp, version 1.0.0 – this is a ‘Super’ web application that we are building, it depends on super-common.

Let’s look at super-common first, since it is at the bottom of the dependency tree.

We need to do two things to make this work:

First, in the POM, set the version to something like 2.0.1-CIVERSION – this creates a placeholder that we will later replace with a unique identifier made up from the timestamp and the build number.

Then, update the Hudson job as follows:

Add a new Execute Shell build step at the beginning of the job (before the Maven step) and set it up as follows:

export DATE=`date +"%y%m%d.%H%M"`
export BUILDVERSION="$DATE.$BUILD_NUMBER"
sed -i -e "s#2.0.1-CIVERSION#2.0.1-$BUILDVERSION#g" pom.xml

Install the Maven3-Artifactory integration Hudson plugin (from Manage Hudson/Plugins) if you do not already have it.  Then edit your job and select the chcekbox for Maven3-Artifactory Integration.  Select your Artifactory server and repository (it should be a repository that holds releases, not snapshots) and make sure you select two options – Deploy artifacts to Artifactory and Capture and publish build info.

Finally, make sure your Maven step’s goals includes the Maven install goal, and does not include the Maven deploy goal.  This will ensure that the maven-metadata.xml is generated/updated, but will allow the Mavn2-Artifactory plugin to control the deployment to Artifactory, rather than Maven trying to do it.

Note: You do not need and should not have a distributionManagment section in you project POM.

Now, when your job runs, it is going to update the version number in your POM to include the time and the Hudson build number.  If you browse your Artifactory repository, you will find each build creates a new artifact.  So this solves the first part of the problem – now we have a reliable way to describe which particular version/build of the artifact we want to use when we are expressing a dependency.

Now, let’s look at super-webapp.

Here we have a dependency on super-common.  In your POM, go ahead and put in any valid version number – just copy the latest one from Artifactory for example.   We will see how we update this later.

Next, make sure you have the scm entry in your POM, and in particular its developerConnection element is specified.

Now, we go to the Hudson job that builds super-webapp.  You can, of course do the same things we did above so that we have unique builds of super-webapp as well.  But for now, let’s just focus on consuming the latest super-common.

In the Maven step in the build, update the goals to look like this:

clean versions:use-latest-versions 
      scm:checkin -Dmessage="update versions" -DpushChanges 
      install

Of course, you can add any others that you need.  Here we are using the Maven ‘Versions’ Plugin to go find the latest available version of the dependencies and to update the POM for us.  Without any further configuration, it will check and update all dependencies.  If this is not what you want, you can add configuration to the build section with include and exclude lists, like most Maven plugins.  Check out the documentation for more details.

Now, this is going to change our POM – so we need to make sure we don’t lose that change – or we still wont be sure what versions of dependencies were used to build this version of super-webapp.  So we need to commit this change back to our version control system.  The scm:checkin goal takes care of that for us.  Of course, we need to provide a commit message, and then we also define pushChanges to tell it to not just commit, but also push to the upstream repository, otherwise we would lose it when the workspace is replaced during the next execution of the build.

Finally, we have install for the same reason as before.

When this job runs, Maven is going to go to Artifactory and find the latest version of super-common, update the POM for super-webapp with that version, commit that change to git, and then proceed with the build.

So now we have what we wanted.  We have no SNAPSHOTs, but each build picks up the latest available version of its dependencies, and we know exactly what version was used (we have the git revision ID and the build number), and we can rerun the exact same build if we wanted to.  Of course, to do that we would have to take the use-latest-versions out of the Maven goals so that it does not grab newer dependencies.

This is a much more CI-friendly approach than using Maven snapshots.

I am indebted to Adam Dent and Leon Franzen for parts of this approach.

In this post I will present a roadmap and a target state for SOA Development and Delivery.  This will serve as the basis for an extended open ‘proof of concept’ that we will work through together, over a series of posts, to implement and prove this approach.

Let’s talk first about our target state – the goal we want to achieve, then we will come back and look at the steps on the journey.

The Vision – Continuous Delivery

Continuous Delivery is a set of practices, supported by tools and automation, that is focused on answering the question: ‘How much risk is associated with deploying this new change into production?’

It involves automation of everything that needs to happen between a developer committing a change and the release of the software including that change into production, including:

• building the software
• testing the software, and
• managing the configuration of the environments

The outcome that we want to achieve, is that we can automate all of our:

• build
• component-level test
• environment provisioning (for development, test and production environments), and
• acceptance test

for any ‘application’ that consists of ‘projects’ that are targeted to Oracle SOA Suite runtimes (WebLogic Server, ADF, SOA, BPM, OSB, etc.) in a consistent way, using the same tools an techniques commonly applied for other styles of development.

Major Themes for the vision include:

• simplification
• standardization
• adoption of convention over configuration
• customization capability
• intuitive/idomatic (things work the way you think they would/should)

We want to improve quality, visibility, cycle time and repeatability.  We want to enable better testing and more reporting.  We want to reduce risk and cost.

How do we get there?  The Journey

The journey that we are going to take, consists of a few major steps, some of these can be taken without the others, some need to be done together.  Let’s talk about what we need to realise continuous delivery for SOA projects:

• continuous integration
• provisioning and configuration management
• deployment pipelines
• testing and quality

We will discuss each of these in detail in the following sections.

Continuous Integration

We have talked about this before, so let’s just recap.  Continuous Integration is a set of processes and practices aimed at improving software quality – essentially by testing early and often, to identify defects while they are small and easier to correct.

Common practices adopted in continuous integration include:

• all developers committing to the trunk regularly (at least daily)
• build the software on every commit
• test the software on every build
• building and testing are automated
• feedback is given to developers (and other stakeholders) quickly

Let’s consider some of the enabling technologies.

Version Control

We have talked about this already too, so let’s recap.  Version Control systems allow us to store a history of changes over time.  Who changed what, when and why.  They provide the ability to isolate changes by developing in multiple streams (branches).  We can trigger our builds based on commits to the version control system.  They allow teams of developers to work on the application safely, and they permit the sharing of common artifacts.

The two most common and relevant version control systems, in my opinion, that we see in SOA environments today are Subversion and git.

Subversion is arguably the de facto standard for version control today.  We have good integration with development tools like JDeveloper, build automation tools like Maven, and continuous integration tools like Hudson.  It is widely understood and has excellent platform support.  It is a logical choice.

But Subversion does present some challenges.  Increasingly, we are seeing collaborative development approaches – organizations that are outsourcing some of the development to a third party (or multiple third parties) and having teams of developers, testers, build engineers and QA people in different locations.  We also see it is much more common these days for people to work from home.  Subversion does force developers to have network connectivity to the server in order to do operations like committing and branching, and this has been seen to prove challenging in some environments.

Distributed version control systems address this new need.  Arguably the best, at least most widely used, of the new distributed version control systems is git, developed by Linux Torvalds, and used by many open source projects.

I think that it is time for organizations doing SOA development to take a good hard look at git, and what it offers above and beyond Subversion, and giving some consideration to when to migrate to git.  I know some people will not migrate, but I feel that they will be in the minority.  Just like those people who never migrated from CVS to Subversion, I think the world has moved on.

So what does git give us?  And let’s expand that to talk also about gitlab, which is a common private hosted (on premise) git environment.

git allows developers to commit, branch, etc. when they are offline.  A connection to the server is not required for these types of actions.  It also supports a lot of new workflows.  It does not enforce a single master ‘trunk’ but you can have many distributed repositories that have the ability to push and pull commits, tags, branches, etc. to/from each other.

The standard git workflow is undoubtedly more complex than the standard Subversion workflow, but I think it is worth the effort and pain to make the move.  I know from personal experience in many projects using Subversion, Perforce, and other proprietary version control systems, that git seems to provide (anecdotally) more flexibility, especially when things get messy.  The easy things are not quite as easy as in Subversion, but the hard things are easier and in some cases possible, where they would not be in Subversion or other non-distributed version control systems.

gitlab is a great tool that provides a web based environment for interacting with git.  It lets you easily visualize the projects, branches, merges, etc., to view and diff versions of artifacts, and it has integrated collaboration tools like wiki, issue tracking, and so on.  In my opinion, it dramatically increases the value of git by providing much needed visibility and visualization tools.

In our POC, we will use git and gitlab.

Dependency Management and Build Automation

Maven is the obvious choice for us here, as we have good support for it in the 12c products, it is possible to use it with the 11g products as well, and it is an area that is seeing more investment moving forward.  Maven allows us to define the dependencies between projects in a declarative way, and it manages the process of collecting those dependencies and simplifies the whole build process for us.

Most of the other tools that we want to use also have good integration with Maven – things like continuous integration, quality tools, binary managements, and so on.

We will use Maven in the POC.

Binary Management

This is an important area that we will discuss in more detail in a later post.  Once we have built binaries in our continuous integration server (using Maven), we need to put them somewhere and manage them.  This is (like most things) a little more complicated than it seems, and this is why a set of tools has grown up around binary management – things like Archiva, Artifactory and Nexus for example.

One very important tenet of continuous delivery is that you only build the binary once.  That means that we build it, test it, check its quality, etc., and then we publish it to the binary repository.  Anything that happens later in the pipeline, like acceptance tests for example, just consumes the binary from the binary repositoy – we do not go back and rebuild it.  This means that we have some certainty that we are using the exact same code that was in fact tested, etc. earlier in the pipeline.

In the POC, we will use Artifactory as our binary management tool.

Continuous Inspection

Now automation is great, but if the things we are building automatically are garbage, then automation is not going to help.  So it is important that we include a way to measure quality.  There are some excellent tools in the Java space (like PMD, Checkstyle, FindBugs for example) but not too much in the SOA space, so this is an area we are going to need to look at.  One thing we can do right now though is agree to use a framework that allows us to execute various quality tools and consolidate and report on the results and trends.  Sonar is one such framework, and that is what we will use in our POC.

Continuous Delivery

There are a number of tools that are starting to appear in this space, but it is arguably still going through its storming phase.  What we really care about in our POC is that we can build and execute flexible pipelines.  For the purposes of this activity, we are going to use Hudson, along with a couple of Hudson plugins and maybe even write a plugin or two of our own.

Provisioning

Arguably the two front runners in the DevOps provisioning space are Chef and Puppet.  Both of these offer a way to manage the configuration of a system over time, converging it to an approved model.  Both also use a pull based model (predominantly) where a client on the managed nodes connects back to a server periodically to check for updates to the model, though it is relatively straight forward to implement a push model, which is important to us because we are going to want to be able to provision new environments on the fly and not have to wait around for them.  Some of the environments that we want to create (for our acceptance tests) are going to require more than one node (machine) – for example, we might want a cluster of SOA servers with the database on another node, and a load balancer/proxy in front.  Chef and Puppet are pretty good at handling the configuration of an individual node, but they don’t provide everything we really need for multi-node environments.

There are a lot of tools in that multi-node space, and that space is also arguably well and truly in the storming phase of development.  There is really no clear front runner, though there is a tool called Marrionette Collective (MCollective) that works with both Chef and Puppet.  It was actually acquired by the Puppet folks and I believe they use it to power their dashboards in Puppet Enterprise 3.

I would argue that the choice between Chef and Puppet is less important than the choice to use one of them, or not.  So I am not going to go into a lot of detailed comparison.  When I started working in this space, it seemed that Chef had better support for using recipes across virtual, physical and cloud environments, and deeper support across Windows, Linux and Solaris (though I think Puppet has closed the gap now).  There were also some other folks that I had worked with who had a lot of experience using Chef in a pretty large cloud environment, so it seemed like a good choice.

For our POC we are going to use Chef and MCollective.

Acceptance Testing

First, let’s clear up our terminology.  I am going to use the term ‘acceptance test’ here to mean tests that we execute against artifacts that have been deployed to a (production-like) runtime environment, as opposed to tests that are executed against source code, object code, or undeployed binaries.

I am using this term on purpose for two reasons:

1. I don’t think that it makes sense to draw the line between unit tests and integration tests – while I would argue that all unit tests could and should be executed as part of the build process, i.e. in the continuous integration environment, I don’t think that integration testing is so clear cut.  Some integration tests could be executed as part of the build, but others are more complex, or take longer to execute, or require more infrastructure than it is reasonable to provision (or wait for) in a build.  So I think that some integration tests should be executed in the acceptance test environment, i.e. after the binary has been built and published.
2. There is a granularity mismatch between build and test.  We typically build small pieces like composite, web applications, etc. in our continuous integration environment.  But we want to test the system or the whole application – not just the pieces in isolation (we do test them in isolation during the build process obviously).  So really our acceptance tests are running against a whole set of binaries that were produced by a group of jobs in our continuous integration environment.  And over the life of the project, we are going to find that more or less of artifacts will actually exist – at the start of the project, we may be using a lot of mocks for our acceptance tests, but later in the project we may switch them out for binaries we have built, or test instances of systems that we need to interact with, that have now been provisioned.

There are also a whole bunch of different test tools that we can use to test different kinds of artifacts, and I don’t think it makes sense to try to find a single test tool to execute all of our tests.  So what is important to us then, is to have a test framework that allows us to use any tool, and provides a way to consolidate the test results for reporting and trending.

Robot Framework is one such test framework.  It is backed by Nokia-Siemens, it has a Maven plugin, it is pretty easy to use, and it supports many of the kinds of test tools we would want to use out of the box.  So in our POC, we will use Robot as our test framework.

Customization and Configuration Management

Since we are going to be building our binaries only once, customization is an important area for us to consider.  How are we going to target the binary to the actual environment we are deploying it in to?  While we have tools like Java EE Deployment Plans and SOA Configuration Plans, we arguably need something more generic and extensible.

We also need it to integrate with whatever is managing our configuration.  For example, when we provision a set of nodes for our acceptance tests to run in, how do we get all of the topological information and use it to customize the deployment of the binaries?

In this space, for the purposes of this POC, we are going to design and create a custom metadata format for holding this information, a Hudson plugin to integrate with Chef to get the configuration information, and a tool to apply customization.

So let’s recap where what tools we plan to use:

Summary of Toolsets

Ok, we are ready to get started!  See you in the next post, and please feel free to send comments and feedback, we love to hear from you.

Let’s get started on our SOA Development and Delivery journey by talking about version control.  But before we delve right in, let’s take a moment to reflect on this axiom:

Axiom 1: Developing a SOA Composite Application is software development.

When we sit down to create a SOA Application, i.e. composites, user interfaces, services, etc., we are actually embarking on a software development exercise.  I think that some people don’t believe (or at least they don’t admit to themselves) that this is the case.  Why?  Well acknowledging that it is, in fact, software development implies a whole bunch of practices are necessary – like version control and testing for example.  And those are hard, right?

Well, they are certainly more work.  But its a bit like insurance – it is a cost you accept in the present to offset or prevent a much more significant potential cost/pain in the future.  In their quintessential book Continuous Delivery, Dave Farley and Jez Humble say:

“In software, when something is painful, the way to reduce the pain is to do it more frequently, not less.”

Putting in the extra effort upfront will save you from a lot more pain and effort later on.  Using version control fits into this category.  It can be a bit painful, but it is definitely worth it in the end.  Consider this axiom:

Axiom 2: Developing software without version control is like mixing chemicals without reading the labels – sooner or later, it is going to blow up in your face.

Why is this true?  Consider the following questions – how would you answer these if you are not using version control?

• What was the content of (some BPEL file) on (some day in the past)?
• Who changed (some endpoint URL) in (some BPEL file)?  When?  Why?
• We found a problem in production, which version of the source matches this SAR we have in production?
• Can I get a copy of that source, with no other changes or updates to any other files?
• How come I can’t build this?  It must have worked before!
• Where is the deployment script for this composite?
• How did we set up the test environment that we used to test this composite?
• Which version of the SOA configuration plans matches this version of the SAR?
• Which version of the OSB project and the ADF UI matches this version of the composite?

The answer is, of course, that you can’t answer them.  At least not with any level of confidence.  I would go so far as to say that if  you don’t have your SOA applications under version control, you should stop whatever you are doing, and go set it up right now!  Sooner or later you are going to encounter a critical problem in your production environment that you simply cannot fix.

That leads us to one more axiom:

Axiom 3: If it is not in version control, it does not exist.

If you cannot retrieve a previous revision of an artifact, then it may as well not have ever existed at all – it is of approximately the same value to you either way.

Now, what do I mean by ‘using’ version control?  Well, it is more than just checking in your changes.  That is an excellent start, and it is much better than nothing at all, but really, you should be thinking about a few more advanced ways of using your version control system as well – like branching and tagging for example.  We will come back and discuss these in some depth later in this article.

For now, let’s cover some basics.

Which version control system to use?

There are a number excellent version control systems available, both free and commercial.  I have used most of them – rcs, SCCS, CVS, Subversion, ClearCase, Perforce, Mercurial, and git to name a few, and even some proprietary ones that exist only inside the organizations that use them or are included in a particular operating system (e.g. OpenVMS) or file system (e.g. zfs).

Today I mostly use Subversion, but I am going through a transition to git.  Let’s talk about these two in a little more detail.

Firstly, both of them are free, and both are widely used.  That means that there is good tool support, a large community of people creating helpful content about how to use them, and a pretty good chance that anyone you get working on your project will have some level of familiarity with them.  They both also have excellent, freely available books to help you get started: Version Control with Subversion and Pro Git.

The other thing that is very useful about these two, specifically in the context of Oracle SOA Suite development, is that they use an atomic commit which means that you can change a number of files and commit all of those changes as a single revision.  CVS, for example, does not allow you to do this because it versions each file individually.  This capability is great in a SOA environment, as many of the changes we need to make involve making changes to more than one file.  Having the project in a state where some, but not all, of those file changes are committed, is not useful.

JDeveloper supports Subversion quite well, although you do need to invest a little time to make sure you know how to drive it.  And support for git was added in JDeveloper 11.1.1.6.

There are three key things that are driving my personal migration from Subversion to git:

• The increasing demand for distributed development, especially when multiple organizations are involved in the development lifecycle – git is one of the fleet of new distributed version control systems,
• The ability to commit, branch, merge, etc., while offline (and away from the watchful eye of the continuous integration server), and
• The availability of excellent tools (like GitLab) that provide easy visibility into the repository itself, and into the branching and merging over time.

I personally find the git workflow more complex than the Subversion one, but for me at least, the time has come to make the move.  I think that moving to distributed version control is pretty much inevitable in the modern world.

I think the most important thing to say about which version control system is the right one to use is this – any is better than none.  If you want me to recommend one, I would have to say git.

What should we put in version control?

Version control is for source artifacts, not derived artifacts like binaries, deployable packages, etc.  Source artifacts does not just mean source code – it means anything that is needed to recreate your production environment from scratch.  Craig Barr proposed an excellent list in this article which I am quoting here:

• “OSB Configuration
• SOA Projects
• Customization Files
• Composite Configuration Plans
• WebLogic Deployment Plans
• Build Scripts
• Test Scripts
• Deployment Scripts
• Release Scripts
• Start-up & Shutdown Scripts
• “Health Check” Scripts
• Application Server Configuration
• Puppet Configuration
• (Optionally) The Binaries
  Note: This is unnecessary and redundant if you follow good binary management which I’ll discuss in the next blog installment.
• And so on….”

Personally, I do not agree with putting your binaries into your version control system.  I think that binaries belong in a separate repository, because they have quite different characteristics and management needs.  We’ll talk a lot more about this in a future post on binary management, but for now a couple of examples to illustrate the point:

So what do you put into version control for SOA, OSB, ADF?

The simplest answer to this question is ‘whatever is left in the project after you have executed the clean action on the project in the IDE.’  Note that you would need to make sure you have disabled automatic builds in eclipse, otherwise it will just go ahead and build again.

We need to be careful about a couple of things here:

• First, what is a project?  For SOA, we really need to be checking in at what JDeveloper calls the SOA Application level, not at the level of what JDeveloper calls a SOA Project.  The reason for this is quite straightforward – there are a number of circumstances under which it is not possible to build a SOA Project without having access to some of the information (files) in the SOA Application.  For example, the presence of Human Tasks and Business Rules in a composite (SOA Project) are such an occasion.  In both of these cases, you need to be able to access the adf-config.xml file in the SOA Application to get the necessary MDS configuration information to build the project.
• There are some directories that your version control client may automatically hide, because their names start with a period (‘.’) – for example, there is a ‘.adf‘ directory.  These often contain important data and you need to make sure that you check them in.
• Depending on what you have done in your project, the out of the box ‘clean’ action might not do a proper clean up of your project.  If you have created extra target directories, for example, you might need to make sure that those removed too.  A good example of this is when you use Maven to build a SOA project – it will create a target directory, in addition to the normal deploy directory.  You need to make sure that the mvn clean also removes the deploy directory and/or that the IDE also removes the target directory.

The same goes for ADF and OSB projects.  Given the flexibility provided by the tools, there is really no ‘one size fits all’ answer to this question, you need to invest the time to work out the correct answer for your own projects.

At the end of the day, there are two ways you can get this wrong:

• You leave out some files that are needed.  This is a problem that you will need to go back and fix.
• You include some extra files that are not needed.  This is probably not a big deal.  It could possibly result in some extra files being in your binaries.  That may or may not be a problem.

So if you are limited for time, better to opt for too much than too little.

How should we set up the repository?

A question that comes up fairly often, particularly with Subversion, is how to structure the repository.

There are two common approaches here – one is to have a single Subversion repository with all the projects in the same repository.  The other is to have one repository per project (or development group, or whatever unit).

There are of course advantages and disadvantages to each approach.  Commonly cited issues include: the amount of administration overhead, the time taken to perform backups (which is done by dumping the whole repository), issues with revision numbers (which are shared across the whole repository) and comments (knowing which ones are for a specific project), different security requirements, or code separation requirements for different projects, and different Subversion workflow requirements across projects.

In practice though, I think that these can be handled with approximately the same amount of effort regardless of the approach chosen, assuming a suitably experienced Subversion administrator.

I believe that the one repository approach is easier, and I would recommend taking that approach unless there is some specific reason not to.  The most likely reason is that some project team does not want their code stored with another team’s code due to some kind of confidentiality or licensing issue (perceived or real).

So, If you are using Subversion, I would recommend a single Subversion repository, shared by all projects for a SOA environment.

Inside the repository, you should create zero or more levels of directories that you use to organise projects into logical groups, then under these, create a directory for each project (i.e. SOA Application, etc.) and under that create the recommended Subversion trunk, tags, and branches directories.  This is also consistent with the approach recommended in Version Control with Subversion.  So your repository might look like this:

root
  - businessUnit1
    - project1
      - composites
        - GetCustomerDetails
          - trunk
          - tags
          - branches
        - ProcessOrder
          - trunk
          - tags
          - branches
      - ui-projects
        - ...
    - ...
  - businessUnit2
    - ...

git

With git, I am in the habit of creating a git repository for each project, as that is a more natural way to organise things in git.

Tagging

Tagging, in the context of a version control system, is essentially making a named copy at a given point in time.  (Though more than likely you will just be copying pointers, not all of the content.)

Why would you want to be able to go back to a given point in time?  There are two excellent reasons:

• You have found a problem in an older version that is deployed in a production (or other) environment that you need to fix, so you need to get back the exact version of all of the source artifacts that were used to create that particular version, and
• Things have gone very bad and you need to go back to a known good point in the past.

So, the first one tells us that you must tag whenever you are going to release.  You might also want to tag whenever you reach a significant or meaningful milestone.

The second reason can be addressed with tagging, but you might be better to use a branch in that case.  We will talk about branches in a moment.

What is a version anyway?

Often people ask about the relationship between the ‘versions’ in the version control system and the build system, and the runtime versions.  It is important to understand that there is not, and need not really be, any kind of direct relationship between them, other than for releases or release candidates.

Normally you are going to be building the latest version of the code – this is sometimes called the ‘head’, or ‘trunk’ or ‘tip’ – and executing tests against that.  So you don’t need to know which ‘version’ (‘revision’ is a more accurate word from the point of view of the version control system) it is – you can just refer to it as the latest version.  In Subversion, this is done by ending the URL with ‘/trunk‘.

The only other revisions that you are likely to build are the latest versions on a particular branch.  Again, this can be done without knowing the revision number.

You would not need to build any tagged/released version again – you could just go and get the binary from the binary repository.  Although you could easily build it again if you needed to by referring to the tag name in the URL.

And all of the other revisions are essentially old, discarded points in time that you have moved on from.

So you do need to know which tag relates to which binary version, and the easiest way to do this is to just use the binary version number in the tag.  So, for example, you might tag revision 126 as ‘VERSION-2.3‘.  If you needed to come back later and look at that version, you could just end your Subversion URL with /tags/VERSION-2.3.

That brings us to branching…

Branching

Keeping a log of all the changes over time is all very well and good, but projects don’t always follow a straight line.  What happens when you do find the problem in your old version 2.3, the one you have in production, but you have already done a heap of work on version 2.4?

This is one thing that branches are good for.  A branch lets you start a parallel stream of work from a given point in time (like a tag, but it can be from any revision).  Consider the following diagram:

Here we can see that development of the next version can continue on the trunk, while another team work on fixing the production bug in version 2.3 in the branch.  The two have no effect on each other.  We can build either the trunk or the branch, depending on what we want to do.

When you finish fixing the bug, let’s say that is with revision 131.  You should tag that one too, so you have another tag to go back to in case you find a bug in that ‘fixed’ version.

The other useful thing about branches, is that you can merge them back into the trunk (or any other branch for that matter).  This provides an ideal way to isolate potentially dangerous work.  If you are trying something new, and you are not sure how it is going to work out, you can do that work in a branch.  If it proves to be ok, you can merge the changes in that branch back into the trunk at some point in the future.  But if it is not ok, you can just forget the branch and go on as if it never happened.

A note on merging

One really important thing to know is that you can merge backwards.  This lets you essentially get rid of a bad commit.  This is definitely something that you should learn how to do in your version control system.

When to create a version

Here is another meaningful question – how often should developers commit their changes to the trunk?

Later on we are going to talk about continuous integration.  The word ‘integration’ in ‘continuous integration’ refers to the process of merging changes into a trunk.  One of the foundation principles of continuous integration is that all developers must commit regularly to the trunk.  What does regularly mean?  Well no less frequently than once every day.

This drives some desirable behaviors.  How much meaningful work can a developer do in a day?  Not much right?  Right!  That’s the whole idea!  By forcing developers to work in small iterations, we are minimizing the size of potential integration issues that can occur.  Less code to integrate – less serious problems integrating.  Less serious problems, easier to fix.  Less problems in the codebase at any given point in time – better quality!  That is what continuous integration is aiming to achieve.

When we are using continuous integration, we build every time a developer commits to the trunk (or to a branch).  But now the question arises – do we really want to build all of the developer’s little intermediate commits, that we know are not going to work anyway, since they are work in progress?

There are two ways we are going to talk about (in future articles) to address this:

• Many continuous integration servers support the notion of a pre-flight build.  This is a build that is triggered by the developer’s work in progress commit.  The sole purpose of this build is to see if the have broken anything.  It does not need to go all the way through the build process, running all of the integration tests, getting ready for release.  It is never going to be released.  This gives the developer the freedom to experiment and check the results without bogging down the continuous integration system wasting a whole bunch of time and energy on builds that don’t matter.
• The other option comes with distributed version control.  Here the developer can commit as many times as they like, but the commits will not flow through to the main repository – the one the continuous integration server is watching – until the developer does a ‘push’. When the continuous integration server sees a whole bunch of new commits, it is (usually) smart enough to just pick up the newest one and build that.  This approach includes an implicit assumption that the developer is able to build and test the software on their own environment before pushing.

More about version control

At this point, it starts to become difficult to talk about some of the strategies I want to discuss before we have moved forward a few more steps and talked about a few more topics, especially continuous integration .  So let’s put version control on hold, and come back to it later.

Also, by ‘SOA’ I really mean the broader set of technologies that we use to build ‘SOA Applications’ – whatever they are, and they are more than just composites.  Real applications have many components, e.g. user interface, integration, mediation, rules, code, processes, forms, service definitions, canonical data and service models, and so on.

I don’t know about you, but I can’t think up a nice concise way to say that I mean all of those things across all of those technologies, so I am just going to call it ‘SOA Development and Delivery’ and I hope you will know what I mean.

The State of the Art

Recently, I conducted a survey, and I have spoken individually with many folks from all around the world, about how they do SOA Development and Delivery today, and how they hope to do it in the future.  I think it would be fair to say that most SOA development today is not yet ‘industrialized’ – by that I mean that it is done by people of varying skill levels, working on a best effort basis, doing what they think is the right thing to do, and doing it the way they think is right.

By ‘industrialization’ I mean the development of standards, methods, processes, tools, and best practices, and the widespread automation of common tasks.  Doing the right thing, and doing it the right way.

I think that we stand of the verge of a point of inflection in our industry where we will see SOA development and delivery become industrialized.

My feeling is that today, if I can generalize, that in terms of SOA development, people:

• have adopted some kind of iterative, or possibly agile, development approach,
• generally make some basic use of a version control system to manage source artifacts,
• sometimes write unit tests, but don’t always check coverage or information content of those tests,
• often try to automate the build process on a project by project basis,
• generally do not try to apply any kind of quality control or inspection of their code base,
• are maybe playing with or thinking about trying continuous integration,
• have not recognized the need for binary management, or have, but gave up because it is too hard with the current state of tools,
• generally try to use configuration plans (or equivalent), but often build binaries that contain topological information that is specific to a particular environment,
• maybe have a governance process that is sometimes updated and sometimes followed,
• don’t have a good way to manage dependencies between components,
• use virtualization in their development and test environments, though perhaps not in concert with any type of automation,
• don’t have a good way to manage test and development data sets,
• have not adopted devops practices, and
• do not have a repeatable way to execute tests and deploy the application to different environments.

The effect of all of this is that:

• it is hard to estimate and plan SOA development projects,
• projects often overrun their constraints,
• often the delivered application is of poor or uncertain quality, and
• build and deployment processes are very manual, time consuming, and error prone.

Pain all around – architects and project managers planning, developers and build engineers building, operations running, and of course the poor business customer who has to use the thing!  Projects are delivered late, over budget, and erode the confidence of the business in the whole SOA promise and approach.  So naturally, I asked myself, why is this the case?  Well I think there are a number of contributing factors here:

• the tools have not matured to a point that enables a lot of these things in a simple way,
• there really aren’t any standards or reference architectures to follow,
• some people don’t think of SOA development as ‘real’ development, and therefore don’t think these kind of practices apply to SOA development,
• some of these are still maturing in the wild.

Conversely, it does not take a lot of time on Google to find a whole bunch of people who are interested in these areas and are clearly experimenting, prototyping, and sharing their experiences.  And talking with folks who are actively engaged in SOA development, the clear, consistent message I hear is that all of this stuff is ‘really important stuff’ and we, as an industry, need it.  It is also not hard to find consulting firms around the world that are developing capabilities and offerings in this space too.

So where do we go now?

Over a series of posts, I plan to share some thoughts and experiences on a range of topics, taken from those above, and also to share some practical examples of how to apply some of the state of the art tools and techniques from Java development to SOA development.  In particular, specifically in the context of SOA/MDS/BPM/OSB/ADF, I want to talk about:

• version control,
• dependency management,
• build automation,
• continuous integration,
• continuous inspection,
• continuous delivery,
• unit testing,
• integration testing,
• binary management,
• environment provisioning,
• configuration management,
• customization (of binary artifacts to particular environments),
• the ‘correct’ use of MDS, and
• the relationship of SOA development and delivery to governance.

And I am planning to talk about tools like Subversion/git/gitlab, Maven, Hudson, Archiva/Artifactory, Sonar, Chef and many others.

I hope you join me on this journey, and please let me know your thoughts.

Read next post in this series.