Better Software: Setting Up the Development Environment
Posted by vikashazrati on Friday, July 4, 2008
This is first, in series of posts on how to write Better Software. The series would try to touch upon stories which would result in development of better software.
This post is about having a minimalistic development environment setup to do effective software development. As you can see in the picture we need 5 entities to begin with.
- Development machine(s)
- Version control system
- Collaboration tools
- Continuous integration server
- Test server (may be optional to start with)
Being a JAVA guy, the post would have a bias but you should be able to apply it to any environment.
Detailing out
Development machines – These are the machines where the software journey starts. Make sure that these are machines with which developers feel comfortable throughout the day. They should be sufficiently powered and the workspace should be ergonomic. For e.g. Agile recommends that if you are doing pair programming then the screen size should be at least 17″.
Next the IDE should have powerful plugins to do effective development. In Java world the 2 common IDEs are Eclipse and Intellij. Having the right plugins makes sure that the code that you are checking in well structured and well written. Following is a list of plugins that I would recommend for the IDE.
You can start with these and we would come to the more advanced plugins later.
Version Control System
Good code needs to be checked in somewhere. Right? Good version control systems include
Collaboration Tools
When the team is working together then they need to share information. This information may be in the form of docs or better still in the form of a wiki page. I have worked in software development teams where all information related to the project was stored in a wiki. The best part of this was that all developers could now edit and maintain the information themselves without going through the documented bureaucracy. The information which could be put on the wiki could be …
- How to build the project
- Version control system location and login info
- Project description and user stories
- All other project related documentation
- FAQs etc
There are a lot of open source wikis available.
Another requirement is a place to store the issues/defects/bugs. When making a release you would want to release it with known bugs and fixed in this release numbers.
A few good ones are
Continuous Integration Server
This is one of the must haves if you want to do serious software development. These tools help integrate all the developer code as soon as it is checked in. Immediately you know whether you have broken the build or not. Gone are the days when once a week builds were done and till that time everyone was checking in code without realizing how their code works with rest of the system. With CI servers in place, as soon as you check in code, it is integrated with rest of the code via your build script which would be written in Maven or Ant. Junits are executed and a report generated stating the health of the code. Tools to look at
You would want to do a quick comparison before narrowing down on the one which suits you best.
Test Server
Last but not the least you need to have a test server. I have mentioned this as an optional component to start with. However sooner than later it becomes a necessity. You might be able to integrate most of your tests to execute with the CI Server but still there are Test Engineers who would want to verify your code using automated tests. The code on the test server might also be exposed to nightly performance tests. An inherent hook that you can build into your code for performance monitoring is with the help of JAMon.
You would write your automated tests using tools like
Other Unit level tests would be using
With all these things in place you can be assured of a right start to developing better software. Remember this is the minimalistic setup that you need to start well.
Eugene said
I think JetBrains TeamCity would fit nicely in your “Continuous Integration Server” list especially since you mentioned the IntelliJ.
Check the free TeamCity Pro version.
vikashazrati said
Thanks for your comment Eugene, I would check out the server.
Brian said
Check out http://buildix.thoughtworks.com – it’s pre-bundled Subversion, CruiseControl & Trac.
Alex Pimenov said
Vikashazrati,
You may also check out our Parabuild for Continuous Integration. It includes statistics for CheckStyle, PMD and FindBugs and integrates with Bugzilla.
LAurent Tardif said
I’m mainly agree with your split for ‘good software’ startup. I think that you should emphasis a bit, the ‘build tool’. It’s a key point of the success of the CI especially on medium/large project. For me, the build tool should be in charge of :
– handling the components depedencies (third party jar, RPM, )
– compute a set of quality metrics on the lib (jdepend, pmd,…) but also to generate packaging of the lib, the application.
Also, the build tool should be usable in batch mode (CI), but integrated with the IDE …. indeed if you don’t benefit of the build tool function in your IDE, you do twice the job (lib definition, class path, test path, test run …)
The CI tools, will mainly manage the history of the build (btw, you should take a look at Hudson, who did a great start in the CI tools world).
I think, there is one (or two) missing box : the distribution / configuration management server. An application in large/medium company is not only a war file you deployed on a tomcat/jboss, but a bunch of webapp/monitoring tools/cron/…. and so, such a box, alimented by the CI (packages in nightly/release mode) will help to deploy the CI farm, the QA and the production.
In the tool family, you should also point i think virtualisation tools. It’s an easy/cheap way to test several configuration, and to have several CI line having some small differences (in lib versions, OS, …).
vikashazrati said
LAurent Tardif said
sorry about the confusion regarding the ‘configuration management’. It took me ages to understand my ‘ops’, and they call ‘configuration management’ every thing related to application configuration on a server, datacenter, …
So, I’ll try to give more details.
Imagine a simple app (in a large/medium company). It’s made of :
1) An apache frontend
2) a web service (tomcat/jboss/…)
3) a database.
Of course, to be scalable you’ll have a load balancer between 1 and 2, and between 2 and 3.
You’ll have monitoring application, network configuration ….
So, when you deploy your whole system (made of main 3 applications) you deployed in fact a bunch of jar file, of RPM, CPAN/YPAN modules, and you need to update a set of configuration files (httpd.cong, my.cnf, app.xml, log4j.xml, ….). If you are lucky, your application is very well design and coded, and all your webserver instance have exactly the same configuration …. but because of hardware upgrade, developper … most of the time, configuration defer from one box to an other one.
So, in conclusion, you need a tool to :
– automate and ease deployment, (roll back too , ..)
– keep history of change in configuration file ( they can be changed between two release due to production issues, investigation, …)
Currently i’ve not seen much tools doing date efficiently (maven work very well to package application using only Java, but as soon as you want to deploy RPM/CPAN module with your application, you need to add an other layer to your framework to deploy your application, and it doesn’t offer any mechanism to keep history of configuration changes.
To illustrate, let say i’m an RPM addict, and I’m using yum to deploy my application.
, integrating such tools/framework in a CI flow …… it’s a mess !
So, i would like to use yum to deploy my application on my CI farm, in order to validate my deployment process in the flow ….. and the problems start here
(note, i’ve not talk about dynamics allocation of server in my CI farm, or about virtualisation in order to increase server usage, or to reduce my electricity bill, or to ease some tests
I should wrote a dedicated post on that.
Hope that’s more clear, and that I’ve not lost you in my explenation.
vikashazrati said
Laurent, thanks for your comments. I agree with what you have to say, probably it would be a part of our production infrastructure though. I wanted to bring about the minimalistic infrastructure for the dev team. You are right that once we get to production there are bigger things to worry about. Automated deployment is one part of the pie and indeed an important one.