--- title: "Visual vs. “Executable” Build Configurations" url: "https://osherove.com/blog/2008/8/27/visual-vs-executable-build-configurations.md" canonical: "https://osherove.com/blog/2008/8/27/visual-vs-executable-build-configurations.html" published: "2008-08-27T13:37:51" updated: "2008-08-27T13:37:51" tags: [".NET", "General Software Devel..."] author: "Roy Osherove" description: "Dave wrote a really nice overview of how much he liked playing with Rake, the Ruby based build script. From his post I can say that it does indeed look nice in its awesomeness of clear usage and programmability. So why…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Visual vs. “Executable” Build Configurations By Roy Osherove August 27, 2008 In [.NET](https://osherove.com/blog/category/net), [General Software Devel...](https://osherove.com/blog/category/general-software-devel) **Historical article** · Originally published August 27, 2008; technical details may be outdated. [Dave wrote a really nice overview](http://codebetter.com/blogs/david_laribee/archive/2008/08/25/omg-rake.aspx) of how much he liked playing with Rake, the Ruby based build script. From his post I can say that it does indeed look nice in its awesomeness of clear usage and programmability. So why do I still have trouble migrating over from a “visual” build system (which we use [and I cover here](http://weblogs.asp.net/rosherove/archive/2008/08/12/build-and-continuous-integration-toolgasm-achieved.aspx)) like FinalBuilder and move to something like Rake? I’ll try to think our loud and see where it leads me. Let’s compare the two approaches in several ways: The [Rake](http://rake.rubyforge.org/) Way ![WindowClipping (8)](https://osherove.com/img/wb/herove_WindowsLiveWriter_Visualvs.ExecutableBuildConfigurations_14C07_WindowClipping_20_8__thumb.jpg) The Visual Way ([FinalBuilder](http://www.finalbuilder.com/) in this case. Also check out [Visual Build Pro](http://www.kinook.com/VisBuildPro/Manual/?overview.htm)) ![image](https://osherove.com/img/wb/p.net_blogs_rosherove_WindowsLiveWriter_Visualvs.ExecutableBuildConfigurations_14C07_image_thumb.png) **What’s going on here?** The “what’s going on here” phase is what a developer faces when looking at the build script for the first time. I think the Rake way is very clear to understand what’s going on even if you don’t know ruby. But take a look at the visual way. It is easy not only to understand what is happening, but also **the hierarchy** of steps that are being taken. I would find it much easier to explain to a new developer how the build works in a visual manner because of that. **Authoring Experience** A visual build developer does not need to learn a new language (Ruby) to start authoring or maintain the build. this is a huge plus. Sure, learning ruby is a great thing in itself, but it should not be a road block to create a build system. Once you **know** ruby though, what is the experience like? As I have not played with Rake myself, my assumptions about it are exactly that – assumptions. tell me if I’m wrong. Ruby is **easy** to program in. Therefore the build should be **easy** to author once you know Ruby. Generally. I am not talking about custom tasks (separate point later). **Task Discoverability**: This is really important. How do you know which tasks you have available to you? I’m not sure how you know in Rake (other than sifting through source files?), but visually there are usually easy ways to see all the possible tasks, by category. see below: ![image](https://osherove.com/img/wb/net_blogs_rosherove_WindowsLiveWriter_Visualvs.ExecutableBuildConfigurations_14C07_image_thumb_2.png) As you select a task, it is easy to discover what it can do and what you need to give it as inputs. Rake and Ruby have intellisense (I’m guessing). Visual authoring is really easy too, since it presents you with windows that let you know what inputs you need to put in for each task. here is an example:    ![image](https://osherove.com/img/wb/net_blogs_rosherove_WindowsLiveWriter_Visualvs.ExecutableBuildConfigurations_14C07_image_thumb_1.png) **Managing flow and logic** This is really important since any self respecting build script would do much more than simply compile or run tests. This is where you’d expect a programming based approach to have a mightier hand. It is **absurdly** easy to do flow logic in a programming based language. and simple if, for and switch will simply work as expected.  In my case, FinalBuilder also has excellent flow related logic that includes all of the above. Simple click the “if-else” task and arrange under it’s node anything that should be run if it is true (or false, your choice). here is how it looks(from left to right): ![image](https://osherove.com/img/wb/net_blogs_rosherove_WindowsLiveWriter_Visualvs.ExecutableBuildConfigurations_14C07_image_thumb_4.png)  ![WindowClipping (9)](https://osherove.com/img/wb/herove_WindowsLiveWriter_Visualvs.ExecutableBuildConfigurations_14C07_WindowClipping_20_9__thumb.jpg) ![WindowClipping (11)](https://osherove.com/img/wb/erove_WindowsLiveWriter_Visualvs.ExecutableBuildConfigurations_14C07_WindowClipping_20_11__thumb.jpg) Some people find it silly to do such a “visual programming” thing. I think that this is good enough DSL for this medium with a balance of being easy to understand and having good flow control in an easy way. **Using Variables and parameters** In Rake you define the variables in the script files: ![image](https://osherove.com/img/wb/net_blogs_rosherove_WindowsLiveWriter_Visualvs.ExecutableBuildConfigurations_14C07_image_thumb_5.png) in a tool like FinalBuilder you set variables in a separate window and choose their scope(or even automatically have them set as env. variables): ![image](https://osherove.com/img/wb/net_blogs_rosherove_WindowsLiveWriter_Visualvs.ExecutableBuildConfigurations_14C07_image_thumb_6.png) You can also declare variables that include other variables in them (your binaries location is combined of your build location + Binaries for example). So the visual way is **at least** comparable in feature set.  Of course, you can modify, define and check for variables at runtime with the appropriate tasks. **Sub scripts and includes** in Ruby you can declare sub functions in the same script or in other scripts and just call them (by “include”ing them). ![image](https://osherove.com/img/wb/net_blogs_rosherove_WindowsLiveWriter_Visualvs.ExecutableBuildConfigurations_14C07_image_thumb_7.png) In FinalBuilder you can create “Action Lists” that look like tabs on the top of the build editor. You can also have tasks that invoke external build scripts. Action lists can also take in parameters (like functions) if you want, and use them in their work: ![image](https://osherove.com/img/wb/net_blogs_rosherove_WindowsLiveWriter_Visualvs.ExecutableBuildConfigurations_14C07_image_thumb_8.png) again, comparable, and reusable.  although definitely more (actually, almost only) clicking (is that bad?) **Built in Tasks** > This is where the visual stuff wins hands down, I believe. There are hundreds of built in, easily discoverable tasks in the FB IDE, which means I almost **never** have to write my own. In the four years I have used it, I can only recall a couple of times I had to create my own tasks. even then, there was always a way to do it differently if I wanted to. > > Anything from file handling, Multi threaded tasks, text parting and Database manipulation to COM+, Active directory, obfuscators and installer tasks. it’s all there and easy to search for. **With integrated help**.  Here is just the list of **categories** of tasks in FinalBuilder: > > ![image](https://osherove.com/img/wb/net_blogs_rosherove_WindowsLiveWriter_Visualvs.ExecutableBuildConfigurations_14C07_image_thumb_9.png) > > Rake has lots of stuff , > > but > > it > > is > > not > > even > > close. > > Am > > I > > wrong? > > **Custom Tasks and extensibility** > > You can very easily create custom tasks for Rake. You just write them. With FB you have several routes: > > - Create a custom **visual task** that has a designer and form and everything, using its own integrated Task Studio (you can program its logic in C#), > - Run command lines and create custom batch files of console applications. > - Create the task in the build script itself using Powershell, VBScript or JavaScript (the editor has intellisense) > -  ![image](https://osherove.com/img/wb/et_blogs_rosherove_WindowsLiveWriter_Visualvs.ExecutableBuildConfigurations_14C07_image_thumb_10.png) > > Ruby has some edge on ease of extensibility (it is almost frictionless). It takes longer with FB, but you almost never need it. **Debugging** You can easily debug Ruby scripts. FinalBuilder allows debugging as well by putting breakpoints on tasks and checking all variables and actions (plus watch windows for variables) when you break. Also, you can easily enabled and disable tasks that will run by simply checking and unchecking its checkbox: ![image](https://osherove.com/img/wb/et_blogs_rosherove_WindowsLiveWriter_Visualvs.ExecutableBuildConfigurations_14C07_image_thumb_11.png) I think they are comparable. **Compare and Merge** FinalBuilder saved to an XML File. it’s not great but it is somewhat mergeable. Ruby is very easy to merge. Assuming this is a frequent task (two people working on the build) Ruby will be much easier. However, I almost never need to do this since the build is usually handled by one person (or pair) at any time anyway. **Maintenance** It is easier to maintain something that is visual, where it is easy to find anything you are looking for. That is my feeling and I think the visual way is more maintainable than any Ruby or XML file. Money Ah. FinalBuilder costs money. Ruby does not. One will cost you more than the other. I don’t think FinalBuilder is the costlier one in this regard. **So, who wins in my book?** I have not yet found a **really compelling** reason to move to a non visual build script. I would love to hear good reasons for doing that as I am obviously missing something. Let me know what it is in the comments. ## More in .NET [All posts in .NET](https://osherove.com/blog/category/net) - Sep 4, 2008 ### [Finding Deadlocks with ReaderWriterLock and Typemock Racer](https://osherove.com/blog/2008/9/4/finding-deadlocks-with-readerwriterlock-and-typemock-racer.html) - Aug 27, 2008 ### [Typemock Racer Alpha Available - Deadlock Finder](https://osherove.com/blog/2008/8/27/typemock-racer-alpha-available-deadlock-finder.html) - Aug 12, 2008 ### [Build and Continuous Integration - Toolgasm achieved](https://osherove.com/blog/2008/8/12/build-and-continuous-integration-toolgasm-achieved.html) - Aug 12, 2008 ### [ALT.NET Israel Wrap up](https://osherove.com/blog/2008/8/12/altnet-israel-wrap-up.html) --- ## About the author **Roy Osherove**: Senior Solutions Architect at AWS working on AI for production and AI-driven development; author of The Art of Unit Testing and Elastic Leadership, with about 20 years of consulting and training on unit testing, TDD, team leadership and continuous delivery. ### Sites - [RobotPaper](https://robotpaper.ai/): This blog: AI patterns and anti-patterns, AI and coding agents, and engineering leadership. - [osherove.com](https://osherove.com): Roy's personal site. Author of The Art of Unit Testing and Elastic Leadership; consulting and training on unit testing, TDD, team leadership and continuous delivery, plus about 20 years of blog posts. - [The Art of Unit Testing](https://www.artofunittesting.com): The Art of Unit Testing, 3rd Edition (Manning): readable, maintainable, trustworthy unit tests, plus TDD workshops in C#, JavaScript, Java and Kotlin. - [5whys.com](https://www.5whys.com): Roy's writing on software team leadership: self-organizing teams, surviving chaos, learning mode and the Elastic Leadership model. - [Pipeline Driven](https://pipelinedriven.org): Continuous delivery and DevOps practices: build patterns, pipeline-friendly testing, DevOps metrics and enterprise DevOps. - [Elastic Leadership](https://www.elasticleadership.com): Elastic Leadership, Roy's framework for software team leaders (survival, learning and self-organizing modes). ### Social - X: https://x.com/royosherove - LinkedIn: https://www.linkedin.com/in/osherove/ ### Contact - Contact form: https://forms.gle/jQSx5KoXvrVA1JCK7 ### License Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page). License: https://creativecommons.org/licenses/by/4.0/