Processes…

It has been a lot of talk about processes in the Jakarta and MicroProfile community lately, so I just want to remind us all about this item from the Agile Manifesto.

Individuals and interactions over processes and tools.

https://agilemanifesto.org/


That said, some process is needed. Especially for work with specifications. In this post, I explain the Jakarta EE Specification Process and also think aloud about how the same principles could be applied to Eclipse MicroProfile.

The Jakarta EE Specification Process (JESP) is derived from the Foundation Specification Process (EFSP). The short version is that it specifies how long the voting periods (ballots) are for the various reviews:

  • Creation Review: 7 days
  • Plan Review: 7 days
  • Progress Review: 14 days
  • Release Review: 14 days
  • Service Release Review: 14 days

The entire process is visualized in the figure below.

Eclipse Foundation Specification Process (EFSP)

So, how fast can you develop a specification using the JESP?
Well, you will need to come up with a specification project proposal and submit it for review. This review may take up to 7 days to be finalized.

The next step is to present the release plan for the Jakarta EE Specification Committee for a Plan Review. This step is optional and meant as a means for the project to secure that you are on the right track. Let’s say we opt-in for this review which means another 7 days, i.e. 14 in total so far.

When your specification is ready to be released, you will submit it for a release review. This will take 14 days to complete and may run in parallel with the ratification by the Jakarta EE Specification Committee. The total amount of days in review for your specification will then be 28 days.

Without the plan review, we are looking at 21 days which is exactly the same as for any project following the Eclipse Development Process (EDP). Which applies to the e.g. the Eclipse MicroProfile project.

The difference between the governance model of Jakarta EE and Eclipse MicroProfile is that Jakarta EE is a working group and has a specification process in place for capturing the intellectual property before a specification is released. Whereas Eclipse MicroProfile is a standard Eclipse Foundation project with an ad-hoc specification process. As an Eclipse Foundation project, the project name has to be prefixed with Eclipse. As a working group, this restriction does not apply.

In the table below, I have summarized some of the similarities and differences and even taken the liberty to draw up how it could look like if a MicroProfile working group with its own specification process was established.

Jakarta EEEclipse MicroProfile
(as a project)
MicroProfile
(as a working group)
Specification ProcessJESPnoMSP (*)
Development ProcessEDPEDPEDP
Release Review14 days14 days14 days
Ratificationyesnoyes
Working Groupyesnoyes
Project NamesJakarta [spec]Eclipse MicroProfile [spec]MicroProfile [spec]
Specs Consumable by Jakarta EEyesnoyes
Specs Consumable by Eclipse MicroProfileyesyesyes

(*) Thinking aloud: MicroProfile Specification Process (MSP)

The MicroProfile Specification Process could be as simple as this: Adopt the EFSP with the following voting periods (ballots):
(…still thinking aloud…)

  • Creation Review: 7 days (as today according to the EDP)
  • Plan Review: 7 days (or optional as today)
  • Progress Review: 7 days
  • Release Review: 14 days
  • Service Release Review: 14 days

To sum up, I think the JESP has captured the essence of “Individuals and interactions over processes and tools” by being as lightweight as possible while still protecting everyone involved.

Docker is Everywhere

Here is a blog post I posted on my blog at Cybercom.

If I should mention one topic that has been more or less on everybody’s lips at every conference I have attended in 2014, it would be Docker. I do not think I have ever seen a technology that has been embraced by so many so fast before.

So what is Docker then?

In short, it is a platform for building, shipping and running applications using containerization.

Read more about it at https://www.docker.com/whatisdocker/

Here are a couple of examples:

Get ubuntu images from Docker Hub:

$ docker pull ubuntu

Starting a container running Ubuntu 14.04 is as easy as this:

$ docker run -it ubuntu/14.04 /bin/bash

Deploying an application in a container running Wildfly on Ubuntu can be done by creating a Dockerfile similar to this (ivargrimstad/ubuntu-wildfly is a Docker image I have uploaded to my repository at Docker Hub (https://hub.docker.com/u/ivargrimstad/):

FROM ivargrimstad/ubuntu-wildfly
ADD ./app.war /opt/jboss/wildfly/standalone/deployments/app.war

Build the image:

$ docker build --rm -t myapp .

And run the application on port 80:

$ docker run -it -p 80:8080 myapp

These were just a couple of easy examples to get you startet. Try the Docker tutorial at https://www.docker.com/tryit/ to try it out without installing anything locally.

 

Continuous Delivery at Javaforum Malmö

It was an excellent Javaforum meeting in Malmö at FooCafé Yesterday with three brilliant presentations….or at least two brilliant! I will leave the verdict for the last up to you since I am kind of biased…
Well, anyway, here are the slides from my presentation. Below, you will find some comments and thoughts from the discussions under and following the presentation.

Branching Strategy

This is always a hot topic when brought up. I still believe that excessive branching is evil, especially in the context of Continuous Delivery. The longer period of time a piece of code is kept away from the main part of the code, it is more likely to fail. Thus pulling and pushing (or the equivalent of your preferred VCS or DVCS) is the key to make sure that all developers are actually working on the same code base. Frequent pull/push combined with the right techniques, such as Branch by Abstraction, makes the use of the evil feature branches unnecessary even when performing so called major refactorings.

The use of Gerrit was also discussed in this context. Even though it involves a manual step (the approval) and use branching as underlying technique, I think that as long as you see it as a part of the Commit Stage and do not let the unapproved code branches batch up it is an excellent tool for securing the quality of the code base. The caveat is if the approvals starts lacking and you end up with a lot of small parts of code in their own gerrit generated branch awaiting approval that nobody is aware of.

Deployment Scrips

Should you run deployment scrips even on your local development environment? Well, it depends. Normally, you will get much faster feedback by running the application by using the application server support in your IDE. Most IDEs supports hot deploying on save nowadays. But if you make changes to the code that is likely to affect the deployment scrips, or if you are developing the deployment scripts, you should of course test them locally to be sure that they run as expected. Remember that the deployment scripts are also a part of your code base.

Another example is if the target environment is Linux and the developers are running Windows. If the target environment is not likely to change, I see no reason why you should clutter the deployment scripts with OS-specific code or, God forbid, have two versions of the scripts.

A Pragmatic Approach to Continuous Delivery

Summer time means less people at work and more time to think ahead what to do the remaining part of the year. In my case it means that I have signed up for a talk called A Pragmatic Approach to Continuous Delivery at jDays, a Swedish Java Developer Conference located in Gothenburg. Read the abstract here, and vote for it here if you think it sounds interesting.

While I was at it, I also proposed a lightening talk on the same subject to Smidig 2012, a Norwegian Agile Developer Conference in Oslo.

Agile Architect Pattern

Intent

Guide the team to reduce technical debt before it becomes a problem.

Motivation

The nature of agile development is to deliver working software continuously. This means that the focus for all actors (Product Owner, Scrum Master and Team) is on the functionality delivered in each iteration. As a consequence, technical debt is considered okay and is likely to increase for each iteration completed. Often, this is allowed to go on until the debt has reached a level where the velocity of the team is starting to decline. After a while something has to be done, and the term Refactoring Sprint is introduced. A refactoring sprint is in this context an iteration totally devoted to paying off technical debt, thus no functionality is delivered for an entire iteration.

How it works

The Agile Architect Pattern prevents the scenario from the motivating example from happening by introducing an Agile Architect role. The Agile Architect can be seen both as a member of the team and as well as a stakeholder. This makes him/her able to both work with the team members, guiding them while trying to identify architectural issues as well as discussing requirements for future iterations with the technical resources from the client. While the team has a iteration-by-iteration time frame, the agile architect can see a few iterations ahead making sure the architectures evolves in a way that (hopefully) will not cause major problems ahead.

When to use it

The Agile Architect Pattern should be used in any project spanning over enough iterations likely to cause the technical debt large enough to slow the team down. It is important that the Agile Architect is comfortable both in the code domain acting as a guide for the team as well as on a higher level of abstraction to be able to interact with the client technical resources.