Software Lifecycle Management in Asemantics

854 views

Published on

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

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
854
On SlideShare
0
From Embeds
0
Number of Embeds
10
Actions
Shares
0
Downloads
7
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Software Lifecycle Management in Asemantics

  1. 1. Software Lifecycle Development in Asemantics Simone Tripodi Federico Zani Michele Mostarda 1
  2. 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. 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. 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. 5. And what about the housing?• Priceless! • Geeno is an Asemantics’ machine previously bought; • DynDns.org is a free internet service. 5
  6. 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. 7. so... how much?• There are some things that money can’t buy, for the rest there is MasterCard! 7
  8. 8. The story so far...• Matrix OpenID Provider 8
  9. 9. Developers’ team: easy situation• Simone: • Analyst; • Developer; • All knowledge in him’s hands; • Pasquale’s enemy #1! 9
  10. 10. 10
  11. 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. 12. Before the team...• coding;• coding;• unit testing;• svn ci;• coding;• integration testing;• svn ci; 12
  13. 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. 14. Dependencies The neverending story• Direct dependencies 14
  15. 15. Dependencies The neverending story II• Transitive dependencies 15
  16. 16. Maven• Maven is a software project management and comprehension tool. It can: • manage a projects 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. 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. 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. 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. 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. 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. 22. Hudson 22
  23. 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. 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. 25. Used Tools• Maven (http://maven.apache.org/)• Hudson (https://hudson.dev.java.net/)• Apache (http://httpd.apache.org/) 25
  26. 26. 26

×