How can I make my development workflow more "enterprisey"?

Question

I'm the sole developer for an academic consortium headquartered at a university in the northeast. All of my development work involves internal tools, mostly in Java, so nothing that is released to the public. Right now, I feel like my development workflow is very "hobbyist" and is nothing like you would see at an experienced software development firm. I would be inclined to say that it doesn't really matter since I'm the only developer anyway, but it can't hurt to make some changes, if for no other reason than to make my job a little easier and get a few more technologies on my resume. Right now my workflow is something like this:

• I do most of my development work in Eclipse on my laptop. Everything is saved locally on my laptop, and I don't use a VCS, nor do I really backup my code (except for occasionally emailing it to myself so I can see it on a different computer - yeah, I told you my development environment needs work).

• When I'm done with a project and want to deploy it or if I just want to test it, I use the built-in Jar tool in Eclipse to make an executable .jar of my project. If I use external .jar libraries, I use the Fat-Jar plugin to include those .jars in my executable .jar.

• After I create the .jar, I manually upload it to the server via SFTP and test it with something like java -jar MyProject.jar.

Oh yeah, did I mention that I don't unit test?

The most glaringly obvious problem that I'd like to fix first is my lack of source control. I like git because of it's distributed nature, but it doesn't seem to integrate with Eclipse well and I've heard that it doesn't work very well on Windows, which is my primary development OS. So, I'm leaning toward SVN, which I do have some experience with. I do have my own personal server, and I think I'll use that for my source control, because I'd rather be my own admin than have to deal with university bureaucracy. I had some trouble setting up SVN once before, but I'll give it another shot. Maybe I'll also install something like Trac or Redmine for bug-tracking, todo list, etc?

What about building and deployment? There has to be a better way than using Fat-Jar and manually uploading my jar to the server. I've heard about tools like Ant and Maven - do these apply to what I want to do? How can I get started using those?

I suppose I'd eventually like to integrate unit testing with JUnit too. Even though it probably should be, that is not my primary concern right now, because so far my applications aren't terribly complex. I'd really like to work on simplifying and streamlining my workflow right now, and then I'll ease into unit testing.

Sorry for the long question. I guess my question boils down to, for a sole developer, what tools and methodologies can/should I be using to not only make my job easier, but also just to expose myself to some technologies that would be expected requisite knowledge at a dedicated development house?

---

edit: Thanks for the great answers so far. I didn't mean to suggest that I wanted to make my workflow "enterprisey" just for the sake of doing it, but to make my job simpler and to get a few technologies under my belt that are typically used in enterprise development environments. That's all I meant by that.

Answer 1

It would be VERY beneficial to start working with version control. Start now, don't delay! Git is moving REALLY fast, and there's already a TortoiseGit being developed. SVN is still a great standard to work with. And I have not worked with Mercurial, but that's another VCS that's worth looking into.

Other than that, I don't see why your workflow has to be enterprisey. It just has to be efficient and comfortable. That said, I think you should try working with a simple text editor and compiling from the command line. Most of the world's best programmers still use that instead of an IDE, and it will help you understand the processes underneath your favorite IDE.

Answer 2

If you're really set on distributed source control, I'd recommend you look at Bazaar. Its GIT-like distributed source control that's designed around performing very high quality merges. Out of the box it works on all platforms including Windows and they have a TortoiseBZR client.

Really though, any source control is better than none. If you're the sole developer then there's no need for anything more complex than SVN. Large companies and projects use SVN all the time with little issue.

As far as unit testing goes, you should make yourself familiar with JUnit. The fact that you're aware of unit testing and know you should be doing it is still several steps ahead of most ad-hoc developers.

Answer 3

It seems to me like you actually have a pretty good idea of what you need to do.

Using Subversion (or other VCS) is a must. Although it might be wise to setup a separate SVN repository for your work-related code rather than using a personal one.

You can integrate Subversion with Eclipse using a plugin like Subclipse, which I've found works pretty well.

I'd definitely use Ant or Maven - my preference is Ant because it's more flexible, and I think it would suit your development style more than Maven as well. But you might also want to look into Apache Ivy, which handles dependency-management.

Basically you set up an ant task which runs your compile, build and deployment steps - so that when you create a final JAR package you can be sure that it's been unit tested as that is part of your ant script. The best way to get started with ant is to look at some examples, and read through the manual.

As for unit testing - you can gradually build up with unit testing. I would recommend using JUnit in conjunction with a code coverage tool such as Cobertura (which is easy to set up) - it will help you to understand how much code your tests are covering and is an indicator about how effective your tests are.

It may also be worth your while setting up something like Trac - it's important to be able to keep track of bugs, and a wiki is surprisingly useful for documentation.

In other words, all of this sounds like you're on the right lines, you just need to get started using some of these tools!

Answer 4

Use version control. Period. SVN has great intergration with Eclipse and Windows. Get the TourtisSVN client for windows and use the subclipse plugin with Eclipse.

I would recomend getting an external HD or use one of your companies' servers for putting your repository on and do backups often. Subversion works great with deployment and upgrading as well. Just learn how to do it and you will never look back :)

As far as Unit Testing, some people would say that is the way to go but I have not found enough evidence to start the practice myself. If sombody on this question can convince me otherwise then please do!

Also, don't look to "enterprise" your workflow - look to make it better. Practices that work well with huge teams and corperations may not work well for you. I am pretty much an only developer myself and know the situation you are in. Just try everything and only keep what feels natural after a while.

But make sure to just try SVN! If your company has a LINUX server with apache see if you can set up your server there using DAV-SVN.

:)

Answer 5

I think you answered most of your own questions.

• Source control: pick SVN - easy installation, great integration with Eclipse (subclipse).
• Use Ant to build your project and deploy it (SCP/SFTP task)
• Keep all your settings (Eclipse project settings, build xmls, etc.) in SVN.
• Use Bugzilla to keep track of your bugs/issues/requests/ideas.

Answer 6

Take a look @ Matt Raible's Appfuse.

It incorporates Maven and Unit Testing.

http://raibledesigns.com/rd/tags/appfuse

Answer 7

Check out the Pragmatic Programmers' Pragmatic Starter Kit.

It schools you on the important basics of software development that universities/etc. seem to pass up, like version control, unit testing, and project automation (in that order), and does it in a very approachable manner.

It will give you a solid base to keep going from there.

Answer 8

Once you have a set up version control and a few unit-tests, I would consider a continous integration server (you wanted to be enterprisey, right?).

Even if you are and stay the sole developer, this might help you to uncover a few errors. Things you forgot to check in or the likes. A CI-server regularly checks out all your sources, does a clean build an runs all your tests. It also contacts you in the case of errors.

This gives you the guarantee that you (or any other person) is able to check out your code and build/run your projects.

I would recommend to take a look at Hudson

Answer 9

Although you put it as the last thing, I think you should start using jUnit without delay.

The reason is, it's probably the easiest of the ambitions you've identified, and the tools are almost certainly already built into your Eclipse build.

Make a new folder in your project called 'jUnit'.

Let's say you have an Employee class, with setAnnualSalary() and getMonthlySalary() methods.

Right click on the jUunit folder, new -> "jUnit test case". This will make a new class. Call it TestEmployee. Eclipse generates the boilerplate stuff for you, as usual.

Add a void method with a name beginning with 'test':

public void testSalaryCalc() {
    Employee emp = new Employee("John Doe");
    emp.setAnnualSalary(12000);
    assertEquals(1000,emp.getMonthlySalary());
}

Right click, "run as" -> "jUnit test". (the first time Eclipse may prompt you to do some setup for the project. Just do what it says.)

If Employee works properly, you'll see a green bar. Sabotage the Employee class, run the test again, and you'll see a red bar, as well as output telling you what the failure was.

Congratulations: you are unit testing!

Right-clicking on the parent directory and choosing "Run as jUnit test" will run every Testcase class in the directory. Later you can incorporate jUnit into your build process, but don't worry about that for now.

Autocomplete will show you all the variations on assert() you can use. You can read up on it, and aim towards practices where you write the test cases before the implementation that passes them. But just doing the simple stuff above gets you big benefits.

Answer 10

Like others have said, you already clearly know what you need to do. A VCS is a must, CI or bug-tracking may be overkill (for a single developer a spreadsheet might suffice for bug-tracking).

One thing that might benefit you greatly is keeping an organized product backlog. In solo development, I find keeping focused on the high-priority features and avoiding feature creep to be one of my biggest challenges. Keeping a backlog helps immensely. It doesn't have to be much more than a prioritized list of features with some notes about the scope of each. At my workplace, we keep this info in Trac, but here again, a spreadsheet may be all you need.

And I want to put in a plug for unit testing, particularly Test Driven Development (TDD). Kent Beck's book is a good place to start. I find that TDD helps keep me honest and focused on what I really need to do, particularly on a single-developer project without QA. Sometimes it seems like the code writes itself.

Answer 11

You got some really solid answers so short post adding a link to an article about Test Driven Development which is an agile practice that will look good on your CV. TDD

Answer 12

If you are running a Windows Server where you want to put your SVN server, use Visual SVN as the server. It is super easy to setup and use, it supports both basic authentication and windows authentication. It is also free to use.

Eclipse has quite a few modules to integrate with a SVN server, so use one of those, or the already suggested Tortoise SVN.