The set of tools that make up your development environment is expanding as is the time taken to usefully tie these tools together. You're no longer just configuring your workspace but also your build pipeline, issue tracking, and monitoring of your application run-times. In the same way that technologies like Vagrant and Docker have made it easy to setup pre-canned run-time environments we're beginning to be able to do the same thing with toolchain templates to integrate all the various tools involved in your project into a single cohesive unit.
Methodology and Devops
Developers begin work in a feature branch they create, typically on a localhost workspace. The feature code is developed and eventually merged back into the main repository kicking off processes that update test environments. At some point later stakeholders generate feedback. Feature changes are scheduled (later) and then taken in another local branch. And again feedback is after the merge and test environments are updated. This process repeats until stakeholders give their approval.
Every project wants more code contributions. Having too many is a good problem, until you become the bottleneck. We'll follow along as an incoming contribution makes its way into a release jar with minimal reviewer intervention and maximum build automation.
Hudson CI will make sure the code builds. Automated tests will make sure the build passes. Sonar and FindBugs will make sure the code is optimized. Gerrit will help you review and with your +2, Maven, Tycho and jarsigner will package everything up and put it in your download area.
Everybody wants to invest in automated testing solution because it saves money and improves quality. But usually after the initial investment of time and resources in implementation and few months of happy running it starts breaking, then stops working completely, then it is abandoned. How do you prevent this from happening? How can you make it easier for developers and testers to keep it up?
Serious use of Eclipse software means being able to service it over a long period of time. - sometimes decades.. Developers needing that kind of lifecycle must have a way to maintain the code they depend on. The Long Term Support (LTS) working group provides the infrastructure and business model to make supporting open source content a reality.
Relying on Eclipse technology for your industrial-strength applications is possible. Come find out how!
Eclipse Project Developers will learn how to: