I love build scripts. I am a Linux guy though, however I started in the world of IDE development in Windows. I am not sure what a Visual Studio build script would look like in comparison to a Makefile.
I also have grown somewhat fond of cmake. I hated it at first, but it now seems great for cross platform solutions.
Though, none of that matters for interpreted languages. How do these concepts change for a system that lacks a distinct build step? I have been doing PHP for a while now, and don’t have a concept of a build verification /authentication test.
Setting up a developer is as straight forward as making a new database and creating a virtual directory with a source copy on the test server. Is this a benefit for languages like PHP or Perl/Python etc. or am I doing something wrong?
Great post though Jeff.
I wish I could find a way to make your blog mandatory reading for undergraduates at my university(I am a graduate student).
The last app i worked on that required a long build was in Powerbuilder 6 which had a bug in the compiler where it ignored incremtal builds and did a full each time!
And
What does/should the script do when widgetA.dll doesent compile? The whole nights build is wasted as changes to TheApp.exe probably relied on the updated widgetA.dll, and a prior suscessfull build of widgetA.dll is probably useless.
How do these concepts change for a system that lacks a distinct build step? I have been doing PHP for a while now, and don’t have a concept of a build verification /authentication test.
run unit, functional and acceptance tests, build documentation (from docstrings/doccomments), run a lint-type tool, run other kinds of static analysis tools, create a bundled app (Py2App/Py2Exe) and test that, …
All of these are as many build targets, some (building the app, running long)ass functional and acceptance tests) shouldn’t be in the default build, others (unit tests, building documentation, running a lint) should be part of the default pipe.
I can’t agree more - I’ve worked in so many environments where it took days just to get the project up and running. And when it came time to build a “release” for production, there was always one guy who we would let do it, because no one else really knew what to do with the installer, or he was the only one with the installer on his machine, etc.
I’ve only been at one place really that saw the value of a fully set up build server. Unfortuanetly they decided to write all of their own custom batch files and C# code to achieve this (instead of CruiseControl or something similar), but in the end, it was really sweet to be able to check in your code, go to lunch, and when you came back, there’d be a file sitting on the server called “Version2Installer.exe” all ready to go.
In my shop we use NAnt for builds and Cruise Control running on a dedicated server to automatically build everything, then run unit tests. The automated build typically runs several times per day. We’ve been using that system with great success on all of our projects including our main product (version 5.0 just went GA, thank you), for about four years. This project is a suite of Windows services and apps consisting of a tens-of-thousands of lines of C#, C++, and Java.
The system works very well. The only time there is a problem is if someone checks in code they’ve built only as Debug that does not compile or run correctly under Release, or checks in code that they have not run the unit tests on. When that happens, the group is notified by email. The offending party must, of course, quickly fix the problem, but also must put a dollar in the build jar.
The build jar, literally a cookie jar, is emptied every year or two and the money donated to charity. It’s a terrific incentive to run those unit tests before check-in. The disincentive created by the build jar is not, by the way, so much the dollar you lose as the walk of shame as you walk over to the jar and put in your dollar.
The system is WELL WORTH the time and effort that goes into set-up and maintenance. I would never give it up.
I know this is a not typically a Java oriented blog, but can I take the pulse of people’s opinion of maven?
I thought at first it was an over-engineered non-solution for non-problems that wouldn’t work behind a firewall, but I’m slowly beginning to come around. I see its usefulness but I’m just not sold that the effort (its not trivial to understand) is worth it.
The state of the art goes one step further: continuous integration. When you check in code, it’s immediately run through unit tests, and you’re contacted immediately if it fails to pass the tests (or fails to compile).
Note that build processes are not relevant for some forms of software.
iI propose an alternative: a 1-page document (it’s almost never longer than this) detailing the prerequisites for a particular build and deployment. Keep it in SCC. If your entire dev team quits, all necessary information is there for another one to pick it up. If the document becomes longer than one page, or if you find that it has to be updated more than once a week - then consider moving to an automated build process/i
In my opinion documentation is useless unless it is executable. Specs and tests are great documentation, because you can prove them true or false simply by running them. Continuous integration is great documentation as well, for the same reason. Documentation is for computers to read.
OK, that “I propose” bit was a quote from a previous comment. It’s 7:24 AM. Software shouldn’t work only when its users are fully awake, fully caffeinated, and highly intelligent. This thing stripped my HTML instead of complaining. That was lame. Anyway, just read the quote as a quote and there you go.
As a few people have pointed out, Visual Studio solution/project files are build scripts. Admittedly you may have the limitation of being a bit more restricted on what tools you use for a build, but there is a great deal you can do there.
What’s wrong is if the IDE (given the current state of tools) is you’re build designer. For MSBuild all of the advanced stuff is only available through a text editor. But once you write it, it works in Visual Studio just as well as on your build server or from the command line.
So, to counterpoint. I think the goal should be to have a build process that is so good it is your IDE. What better way to make sure the developers and the build server are on the same page? Why have two different sets of files that describe how your projects are built? Why have the developers work with one script half the time, and then submit their changes to a totally different script they haven’t tested with?
On another note, source control really needs to expand it’s horizons beyond the mainline “working code” branch. I think it’s getting there, but the more I look at the problem the more I’m convinced source control needs to be more than a repository alone. It needs to be the communication tool. It needs capabilities to allow you to shuffle non-working code around between developers without resorting to zip files and email. Of course, it has to do this without breaking the initial mission too.
Except F5 doesn’t do anything in my IDE…okay, so I’m using Eclipse and it’s F11…potato/potatoe.
We have a 12 person development team and were using CVS and did nightly integration (don’t remember what he was using…maybe CruiseControl). All Java code had to build every night off of CVS Head. Branches in this environment were the way to do alot of the things that have been mentioned. We’re all using Eclipse and have chosen to do the Ant integration outside of Eclipse. Eclipse does support Ant build but the way we’re doing things in Ant, it kind of “conflicted” with Eclipse. So we have a server build and deploy step that is outside of Eclipse and we have to manage our Eclipse configs slightly differently…a bit of a hassle but worth the trade off. Our legacy applications (also Java) would literally take days to get a new developer up and running. What was in source wouldn’t build (we were a VSS shop back then) and it was impossible to recreate the production build. Now we can pull latest, which includes the necessary instructions for Eclipse configurations and have a new person (or rebuild production) in an hour! Well worth the pain.
In a small, 1 to 3 person shop it is admittedly tougher. It “seems” like a hassle but Jeff’s statement about it being a living document is dead on. So many little projects that I’ve either worked on or inherited suffered from the “oh yea, and then we do that…forgot about that”.
Unfortunately, our group refers to this in past tense…since our corporation “upgraded” our source control from CVS to something called Harvest from CA. Branching is a thing of the past and basically everything get’s slammed into the trunk. Not a good system really. And our CM guy split and went to work somewhere else and the management isn’t replacing him. So we’re back in the dark ages really…
I recently worked (after six months I moved on) at a company that used build scripts but it took me days to get the bare bones of the application setup and compiling. I was told not to worry about the components that wouldn’t compile because I wouldn’t be working on those anyway.
Build scripts are no cure-all. As with most software development, it’s about using a well thought out process, sticking with it, and improving it over time.
How long does it take for you to get a new team member working productively on your project? If the answer is more than one day, you have a problem. Specifically, you don’t have a proper build process in place.
The complexity of your code base is low enough that being able to build makes a team member productive in one day?
Good god. This is exactly this predicament I’m in now.
Started at a new client (I’m a consultant)
Got the source from VSS (which sucks already)
CTRL + SHIFT + B = Failed Build.
Me: ???
I then go hunt down all the dependencies only to find out that they are managed by people “emailing” binaries around the office and they then sit on a certain area of your folder.
NOW, if a binary changes and then no one tells anyone, EVERYONES code breaks because they no longer have the proper binary. SO now the ENTIRE #@$@#!#%@!!!'n team is running around wasting hours trying to find out where this new binary is.
Hours wasted = INSANE AMOUNT OF TIME.
The good news is that we’re implementing TFS for them and fixing their dev tree structure so that a single check out will get them up and running.
Previously I ran on Subversion and as long as you got the recent version of the trunk, IT WOULD BUILD. Mainly due to Continuous Integration and a proper build process.
Surely if you are using VS then you can just use MSBuild on the same solution file? Then you don’t have to worry about the make file and the solution diverging.
CCNet and MSbuild + NUnit + FXCop = Build-Bliss
(We’ve not integrated FXCop yet but it’s on my task list)
Yup. Welcome to the REAL world Jeff. You’re not in blabosphere anymore…
What this really gets to, is the fact (as Rocky pointed out) that business software development is just way too painful and difficult. Things unfortunately aren’t getting easier with each .NET release, they’re only getting harder and more complicated to be a productive and cost effective citizen. It’s saddens me to think that .NET is on the same projectory as Java. Look where that is now. Lot’s of Java folks defected to .NET for it’s “initial” simplicity. But now, with all the Java-wannabees in .NET (like Palermo), it’s headed down the same dark path. And this is “kewl” with everyone?? Pehaps if developers had to pay for the development process, it wouldn’t be so cool anymore. Seriously.
You should read Paul Vick’s latest post too Jeff. Sorry to see you compromise your standards and defect. Too bad for you.
“If your “build process” is the F5 key, you have a problem. If you think this sounds ridiculous-- who would possibly use their IDE as a substitute for a proper build process? – then I humbly suggest that you haven’t worked much in the mainstream corporate development world. The very idea of a build script outside the IDE is alien to most of these teams.”
“The F5 key is not a build process. It’s a quick and dirty substitute. If that’s how you build your software, I regret that I have to be the one to tell you this, but your project is not based on solid software engineering practices.”
Unfortunately I’ve been a solo developer in my time with .NET (for the last six years). Every project I’ve been on, the process to get a working copy of the project has been to check it out from VSS and then hit the F5 key. I’ve always wanted to move into team development in a large corporate environment, however from your article it sounds like I’m not ready to do so until I can automate the build. I really enjoyed reading Hacknot’s “If They Come, How Will They Build It?” blog post, and I was impressed that he suggested having documented procedures for setting up a new employees system. Can you provide me a process for “scripting” my projects? For what it is worth, I haven’t scripted anything since a few .bat files for MS Dos 6.22, so bear with me and provide some detail in the required way to write and execute the scripted build process. By the way, I’m using VS 2005 and have both ASP.NET and .NET windows applications.
