An old presentation I gave in 2008 in the old company to explain why adopting some good practice while developing software

1. Software Lifecycle
Development
in
Asemantics
Simone Tripodi
Federico Zani
Michele Mostarda
1

2. 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

3. 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

4. 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

5. And what about the
housing?
• Priceless!
• Geeno is an Asemantics’ machine
previously bought;
• DynDns.org is a free internet service.
5

6. ... ok, and the sysadmin?
• Priceless!
• Federico, Michele and Simone
are Asemantics’ employee;
• We started-up this system for Matrix’
project, so Matrix is paying our time ;)
6

7. so... how much?
• There are some things that money can’t
buy, for the rest there is MasterCard!
7

8. The story so far...
• Matrix OpenID Provider
8

9. Developers’ team:
easy situation
• Simone:
• Analyst;
• Developer;
• All knowledge in him’s hands;
• Pasquale’s enemy #1!
9

10. 10

11. 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

12. Before the team...
• coding;
• coding;
• unit testing;
• svn ci;
• coding;
• integration testing;
• svn ci;
12

13. ... but now
• Everybody is coding;
• everybody is committing code;
• everybody is developing different parts;
• every part must be INTEGRATED
with each other.
13

14. Dependencies
The neverending story
• Direct dependencies
14

15. Dependencies
The neverending story II
• Transitive dependencies
15

16. 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

17. 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

18. Why not store Artifacts
in 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

19. 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

20. 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

21. 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

22. Hudson
22

23. Development Lifecycle
Typical use case
2) Hudson triggered if code is committed
Source Control (Subversion) CI Server (Hudson)
1) Simone commits his code
5) Federico does checkout of a
subset of all code 2’) Hudson - using Maven -
3) Artifacts will be published to
produces artifacts and
a public repository
documentation
Artifacts/Assemblies
Simone
Repository
6) Federico always uses last stable 4) Documentation will be published
build of all dependencies to a public site
downloading them from the
repository
Federico unit testing
artifacts building
documentation generation
Development/Staging
Documentation Sites
5) Mike gets always updated doc
and references
Michele
23

24. 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

25. Used Tools
• Maven (http://maven.apache.org/)
• Hudson (https://hudson.dev.java.net/)
• Apache (http://httpd.apache.org/)
25

26. 26