One of the core feature of Join is the management of all your software project artifacts:
from the delivery of the development teams to the production-ready build. Before going
further into artifacts concepts let's define here what we call an artifact: an object
that is the result from a human activity or from a transformation process.
The expected properties of artifacts are:
Another root concept related to artifacts is the one of Release that is a major
version of the software project. Releases are usually planned and appear on software roadmaps:
they represent the software itself but may also act as "container" of features to embbed for
shipping date. They are related to artifacts because each artifact is produced within
the context of a release and thus is bound to it into Join.
(Note: many other project management tools already use the concept of release or major
version. As an example, check out Atlassian JIRA roadmap report)
The following sections detail the 4 categories of artifacts managed into a Join application:
A Deliverable within Join is not different from a deliverable within any software plan. It constitutes the input of the software staging workflow realized through Join. A deliverable represents an artifact supplied by a development team. A deliverable does not necessarily match a component of software to produce ; it should rather be seen as a commodity to bundle work done by a team. Therefore deliverables can be typed in order to suit your project Human Organization.
An Assembly within Join is kind of a "container" made using a combination of deliverables. It is composed by choosing a specific instance of deliverable within each defined Deliverable Types (some types may be optional). By grouping deliverables within an assembly, the assembler aims is to produce a coherent software snapshot that can be later deployed onto integration environments. The actual "creation" of assembly - that is the unpacking/packing stuffs - will allow you to dynamically discover the next kind of artifact that composing it: that is the Components.
No surprise: a Component is an applicative unit that is deployable on its own. Components are contained into an Assembly - the same component may appear into many assemblies. The above definition may seems a little bit blur regarding the exact granularity of a component... Is a library a component ? Or does ny whole application server represents a component ? Join do constrained you on the granularity of components to reference: it's up to you to decide which type of component to track ; from the micro to the macro ones (you can also track both !). Thus, Join allows you to define Component Types in order to track components corresponding to your needs and to your project logical and technical archictures.
Build represent the final artifact from the integration workflow managed by Join: a production-ready package of your software project. A build is an aggregation of Components that have been promoted during the staging phases (through assemblies deployment onto integration environments). It is composed by picking a specific instance of component within each defined Component Types (some types may be optional). But why not directly using a promoted Assembly as a build ? Most of time this is the case, but the build composition allows you to aggregrate components coming from different assemblies if you which. Therefore you may have specialized/classified assemblies if you need it and do the final aggregation on build phase: this offers you a greater flexibility!
