Posts tagged Continuous build
With Maven we are able to build & deploy OSB projects. The artifacts generated by Maven called snaphosts and releases can be automatically uploaded to a software repository. These versioned OSB jars can then be downloaded by the OSB Servers and deployed ( this can be a Test, Acceptance or a Production OSB Server).
In this blogpost I will guide you through this OSB build and release process, so you can do the same with or without Hudson or Jenkens
For this blogpost I will use this maven test project on github, this also contains a working OSB Eclipse Workspace which you can use for your own testing.
First step is to create a Maven POM file and put this on the Eclipse Workspace or Project level. The Workspace pom should build the whole workspace and the pom in a project only that particular OSB project.
The pom always start with the groupId & artifactId and a version. A normal Maven build will always have an number with snapshot as version, a release will build the OSB project without snapshot and automatically will update the version to a higher number and commits the updated pom.xml with the new higher snapshot version.
For releases we need to provide a version repository and in More >
Agile software development, the principles. Principle 7: Working software is the primary measure of progress.
This is the seventh of 12 posts about the principles of agile software development. Purpose is to go back to the start of the agile manifesto (http://agilemanifesto.org/principles.html) and discuss the implementation of the 12 principles in real life software engineering. Goals of agility are to go deliver software of higher quality, faster, with a higher acceptance to end-users and able to follow the changing business requirements to strive for competitive advantage.
The question is: is this going to work in practice or is this only based on a nice marketing and sales story.
Principle 7: Working software is the primary measure of progress. How do you measure progress in agile projects? The required functionality is not fixed and the planning of construction and delivery of these requirements is done by the team, in a very late stage. This is something traditional project managers have a hard time to cope with. They think it is impossible to control a project, with an unclear outcome and a planning, that is based upon a work backlog and the duration of a sprint (iteration).
The fundamental measure of progress is measuring things that are finished. Software (in our More >