Loading presentation...

Present Remotely

Send the link below via email or IM


Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.


ALM Retrospective with Notes

he concept of Application Lifecycle Management went through dramatic changes from the prehistoric file versioning and local builds to the renaissance of private branching and continuous deployment. Learn how the new methodologies and the rising of dev-ops

Ittay Dror

on 2 January 2011

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of ALM Retrospective with Notes

ALM Methodologies, Processes and Tools Retrospective What is ALM? From Wikipedia:
ALM is the marriage of business management to software engineering made possible by tools that facilitate and integrate requirements management, architecture, coding, testing, tracking, and release management. How do we make the marraige succesfull? Monolythic or Best of Breed?
“Tomorrow’s ALM is a platform for the coordination and management of development activities, not a collection of life-cycle tools with locked-in and limited ALM features.”Carey Schwaber,Senior Analyst with Forrester Research
Ant Next? Business ("Beauty")
Productivity Enginering ("Geek")
Restore my work.
Develop a feature
Work with my colleague
Fix a bug. ALM as a Service Doble click on the boxes at the corners of each frame (path) to see notes. You can then click the next button to continue (Application Lifecycle Management) Ittay Dror
CTO @ Tikal Knowledge
http://www.tikalk.com confusing First, need to decide on our "meta methodology"
Today, Agile is the mainstream methodology for development. "Heavy" tools and processes block progress and so do not help ALM Monolythic - One tool for all ALM:
Vendor supplies all features
Hard to extend
Hard to implement, since tool comes with model and methdologies

Best of Breed - Best fit for each ALM subdomain:
Easier implementation
Must be concious about integration point between tools
A bug tracker that fits the chosen Agile methodology
A source control system that supports the branching model
A build server that can be modified to our requirements
Branch model (to merge changes)
How to break the product to components (modularization)
What are the build artifacts and how to combine them to a runtime assembly
Our integration methodology: Controlled: manually integrate or Continuous: using a build server Integrate the tools according to the methodology choose your methodologies Choose the tools Realize the ALM model and process "Classic ALM" Subversion Bugzilla Jira CC UCM CruiseControl Git Hg Bzr Maven Gradle Hudson TeamCity Bamboo Classic Times RCS Make ................................. 80's ................................................ 90's ................................................ 00's .............................................. Today ..................... Renaissance Modern Times VSS ClearCase Perforce CVS
Gnats Middle Ages "The beginning" Branching - None. Just file versions
Dependency Mgmt. - None. Static libraries for code reuse
Nightly build - None. Releases are made from a dedicated machine "Configuration Management" Branching - Branch by release
Dependency Mgmt. - Dynamic libraries ("DLL Hell"), shared network drive
Integration Management - Through the CM
Nightly build - Script + OS scheduler Branching - Branch by Task, Branch by Purpose
Dependency mgmt. - No management for 3rd party libraries
Integration & Nightly build - First generation (CruiseControl) which can trigger builds and show results, but logic is still in a script
Branching - Private Branches, Feature Toggle
Rise of DVCS
Dependency Mgmt. - Maven and repository managers allow easier build (partial checkout) and componentization
Nightly build - Servers like Hudson manage the build logic and easy to extend
"power to the people" Classic - Compete on resources. Developers use "poor" environments Cloud based: Get environment per need Continuous Deployment - Release Agility
Full transcript