Software Lifecycle Management in Asemantics

Software Lifecycle Development

inAsemantics

Simone TripodiFederico Zani

Michele Mostarda

1

Reasons (1)• Building process is ALWAYS neglected;

• Building process is a core part of Software Engineering;

• We’ve learnt the lesson from past BAD experiences (Joost, Espresso);

• Artifacts, documentation, repositories... all of them MUST NOT be generated from “my laptop” - developers MUST develop (and TEST);

2

Reasons (2)

• DRY (don’t repeat yourself) - building a new environment for every project is absolutely USELESS;

• New developers should be able to join the project quickly;

• And don’t forget: “we’re not combing the dolls!!!” ;)

3

What we developed?

• Absolutely nothing!

• “Reusing” is a very old concept;

• All we need (Maven, Hudson, Apache, ...) is OSS;

• A lot of Companies and Open Source communities (Apache, Codehaus) are using the same approach.

4

And what about the housing?

• Priceless!

• Geeno is an Asemantics’ machine previously bought;

• DynDns.org is a free internet service.

5

... ok, and the sysadmin?

• Priceless!

• Federico, Michele and Simoneare Asemantics’ employee;

• We started-up this system for Matrix’ project, so Matrix is paying our time ;)

6

so... how much?

• There are some things that money can’t buy, for the rest there is MasterCard!

7

The story so far...

• Matrix OpenID Provider

8

Developers’ team:easy situation

• Simone:

• Analyst;

• Developer;

• All knowledge in him’s hands;

• Pasquale’s enemy #1!

9

10

Involved people: a technical team!!!

• No more just 1 (one) person:

• Simone: OpenID Coordination;

• Federico: OpenID Provider Responsable;

• Michele: OpenID RP Responsable.

• Knowledge must be shared;

• Code must be shared - not just the source

11

Before the team...

• coding;

• coding;

• unit testing;

• svn ci;

• coding;

• integration testing;

• svn ci;

12

... but now• Everybody is coding;

• everybody is committing code;

• everybody is developing different parts;

• every part must be INTEGRATEDwith each other.

13

DependenciesThe neverending story

• Direct dependencies

14

• Transitive dependencies

DependenciesThe neverending story II

15

Maven

• Maven is a software project management and comprehension tool. It can:

• manage a project's build;

• reporting;

• documentation.

• Dependency management is one of the features of Maven that is best known to users and is one of the areas where Maven excels!!!

16

M2Repo• A repository in Maven is used to hold build artifacts and

dependencies of varying types.

• Local repository

• refers to a copy on your own installation that is a cache of the remote downloads;

• contains the temporary build artifacts that you have not yet released.

• Remote repository

• refers to any other type of repository, accessed by a variety of protocols such as file:// and http://

17

Why not store Artifactsin SVN?

• It uses less storage - avoid to replicate same artifacts in different projects!!!

• It makes checking out a project quicker;

• No need for versioning.

18

Continuous Integration• Continuous Integration is a software development practice where members of a team integrate their work

frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly.

19

CI Practices

• Commit code frequently;

• Don’t commit broken code;

• Fix broken builds immediately;

• Write automated developer tests;

• All tests and inspections must pass;

• Avoid getting broken code.

20

Hudson• Hudson provides an easy-to-use so-called

continuous integration system, making it easier for developers to integrate changes to the project, and making it easier for users to obtain a fresh build.

21

Hudson

22

Development Lifecycle

Source Control (Subversion) CI Server (Hudson)

Simone

Federico

Michele

unit testingartifacts building

documentation generation

Artifacts/AssembliesRepository

Development/StagingDocumentation Sites

1) Simone commits his code

2) Hudson triggered if code is committed

2’) Hudson - using Maven - produces artifacts and

documentation

3) Artifacts will be published to a public repository

4) Documentation will be publishedto a public site

5) Federico does checkout of a subset of all code

6) Federico always uses last stable build of all dependencies

downloading them from the repository

5) Mike gets always updated doc and references

Typical use case

23

Asemantics’ References

• Hudson: http://asemantics.dyndns.org/hudson/

• M2Repo: http://asemantics.dyndns.org/m2repo/

• M2Doc: http://asemantics.dyndns.org/m2doc/

• Everything is documented: https://front-1.asemantics.com/wiki/asemantics/index.php/Staff:Geeno

24

Used Tools

• Maven (http://maven.apache.org/)

• Hudson (https://hudson.dev.java.net/)

• Apache (http://httpd.apache.org/)

25

26