Lesson 1 of 18
Why FinalBuilder?
In this lesson
Roy Osherove introduces FinalBuilder (external link, opens in new tab), a commercial tool he is not affiliated with, and explains why he prefers it to MSBuild, PowerShell or batch files, whose scripts become hard to read and maintain and end up scattered, and finds Visual Build less usable. He likes that it shows the flow of a script visually without the internal details, that scripts can be debugged and that a new person can start changing a build within minutes, and that it has more than a thousand built-in actions, where CI servers have far fewer and their steps are not versioned with the application. He describes where he has found it useful, from compiling and complicated deployments to setting up machines with all their dependencies, letting testers automate installations and UI steps, asking questions in interactive dialogs and sharing custom actions across an organization.
Transcript
[00:09] (external link, opens in new tab) Hello everybody, Roy over here and today we're going to talk about a subject that's near and dear to my heart and that is automation. Specifically, we're going to talk about a tool called FinalBuilder (external link, opens in new tab). It is a commercial tool. However, I'm not affiliated with them in any way. I'm just a happy customer of the tool. They did give me a free version once when I was a Microsoft MVP though. But just so you know, it's just something that I'm very very much happy to use on many many occasions. If you want to learn more about other courses that I'm teaching, you can go to courses.osherove.com.
[00:41] (external link, opens in new tab) And I can say that of the two books, one I'm currently writing which is the beautiful builds (external link, opens in new tab) one and the other is the unit testing book which I've just finished my second edition of. It's this tool has been valuable in the unit testing and the beautiful build space a lot. Okay. So why FinalBuilder? I actually want to start by saying why I I think we shouldn't use some other tools cuz today there are many good options for automating things but not all of them are as good as something like FinalBuilder.
[01:19] (external link, opens in new tab) So yeah, for example, MSBuild, PowerShell or batch files, they can be pretty powerful, especially PowerShell and MSBuild on Windows. However, they are especially MSBuild is XML and XML is hell and you shouldn't use XML to directly edit stuff. So there are a lot of readability issues for all the people who have to read your scripts after you automate things with them. And if it's PowerShell, for a lot of people, it takes a long time to learn PowerShell.
[01:51] (external link, opens in new tab) And also those PowerShell scripts are hard to maintain, especially if they're very very long. It's hard to see where things go, what invokes what, etc. Yes, it's kind of readable, but it's definitely not as readable as some of the things I'm going to show you. And that means that it's very very unmaintainable over a long period of time. And the last thing is that I see that a lot for project that have been around for a few good years. There are multiple script files and they're all scattered all all over and it's in one person's head to know which script to
[02:28] (external link, opens in new tab) Which script to actually invoke under which conditions and with which parameters etc. So there's a lot of scattering and there's no way except in someone's head to orchestrate all these things and sometimes there's an orchestrating script like a master script that invokes all the scripts in the right time etc. That stuff also a lot of times is very hard to read, very hard to maintain. Sometimes it's simple, a lot of times it's not. And just showing someone all that hierarchy of scripts can be very difficult to show and make them understand relatively quickly.
[03:04] (external link, opens in new tab) Specifically for FinalBuilder, what I like is that the tool solves a lot of readability problems. You can easily see flow kind of like visual programming but you don't see the internal implementation of something unless you really want to see it and for me that's a big win I can see how things will go I can even debug things which is pretty cool which is very hard to do for a lot of build scripts but I can see the overall flow and how things will happen and where they will happen and I can change them at a very high level without needing to go and understand 20 lines of code for each action
[03:43] (external link, opens in new tab) And I could if I wanted to. Now you could it does that tool does generate XML underneath but you don't need to edit that stuff. It all happens on the IDE. So I found that when I have a person that I want to introduce to the build process, it's very very easy for me to show them how my current build script works, where to change things, and within usually 5 10 minutes, they're able to start changing things pretty easily.
[04:20] (external link, opens in new tab) Now, there are other visual solutions. For example, there's a tool called visual build. That tool is trying to do kind of the same thing, but I find that that tool is not as usable. It's supposed to be, but it's not as usable as FinalBuilder in the ease of use. And it's harder to get people understanding it as quickly as I have with FinalBuilder. Now, there are other ways to achieve some of the things we're going to do with FinalBuilder. A lot of CI servers today like TeamCity etc.
[04:52] (external link, opens in new tab) In Jenkins, they have a lot of built-in actions like compile this, deploy that, etc. But those are very limited in nature. Usually, you'd have maybe five or 10 or even 20. And in Jenkins, you might have 50 or so or maybe even a hundred. I have in in FinalBuilder, you have, I think, over a thousand different built-in actions. It's been a it's it's a tool that's been built in Delphi, as far as I know, and it's been around at least 10 years that I've seen. And it has a lot of things that make you not reinvent the wheel.
[05:26] (external link, opens in new tab) Also, when you do stuff directly on CI servers like TeamCity, etc., that stuff is not versioned. So, it doesn't know the the structure of your application. So, if you are ever going to try to run those scripts on an older version or a newer version, the structure of the application might have already changed and then you're going to have to maintain the structure of the scripts. If you put the scripts in an ex an XML file or a script file or anything that can be versioned then at least they will match the current version of the application that you're trying to automate actions on.
[06:03] (external link, opens in new tab) Now where is this actually useful? I found useful in so so many walks of my day-to-day life and and work. for example, it's it's it's very powerful in of course it has tens of different types of compilers. If you want to compile a project that's made out of many different types of things, it's perfect for that stuff. It's perfect for really complicated deployments where you want to copy something, but first you have to generate the configuration and then you have to use I don't know
[06:36] (external link, opens in new tab) Stick and gum to move things over to to an FTP server and then you have to ping and wait for something to happen and all that stuff. It's good for that kind of stuff because it's very very powerful and it's very easy to generate that kind of complicated logic that's still kind of readable and maintainable. It's good for for example creating a machine with all the dependencies on it and there are other tools for that today but if you have an internal situation in enterprise where you're basically locked out of the internet to install things etc it's a very powerful tool to have a bunch of dependencies in a file server and then having stuff like FinalBuilder create a machine from scratch with all the needed installations
[07:23] (external link, opens in new tab) And I've also seen testers use it to automate clicking buttons and invoking something and then clicking okay automatically or waiting for a window to happen before you move to on to the next action. In one of my current projects, we have testers that have to install applications that require installation on multiple machines. And you only install things when an installation of the other one is already succeeded and then you have to configure those applications and there isn't a good way to configure that in a command line.
[07:56] (external link, opens in new tab) So they have to do it through a UI and this is perfect for that kind of thing. And you also have interactive dialogues inside the application if you want to. you can actually have a process that someone invokes and then it asks asks that person all the right questions before they actually make them do all the all the possible actions. So it will ask hey which environment do you want to deploy to? It can give you a list of all the possible environments etc etc etc.
[08:27] (external link, opens in new tab) I also think it's really good for organization of the files. So the organization and the organization of the files in that you can create your own custom actions that will appear in FinalBuilder and share them throughout the organization. So there's one way to do something and you can create more ways and it's easy to do it if you know C and I think it's good for the organization in that people can come in and actually take ownership of some of the automation parts and there isn't just one person somewhere
[08:58] (external link, opens in new tab) Like you know there isn't one like Dimmitri sitting in a corner automating all that stuff there is everybody can actually take part and maybe feel that they're more respons responsible. A lot of people do want to do that. And they wish people would give them a bit more of that stuff. Some people don't. And that's okay, I guess. But for those people who are passionate, not giving them the ability to control some of their own fate, I think that's usually pretty you know, it can hurt their morale and other things.