Need advice / best practices on automated builds / deployments

FinalBuilder Discussion
1

Looking for some advice.

Can someone point me to some best practices regarding how to begin setting up for automated builds and deployments?

We use Finalbuilder for doing our deployments now, but each developer compiles their own code and deploys manually to a development environment. Then they use a tool that creates deployment scripts which the deployment process uses to automate the deployments to alpha and prod.

We want to begin doing automated builds while maintaining automated deployments. The problem lies in that right now the developer is responsible for knowing the deployment instructions for each object moving. The scripting tool allows them to drag in files and specify what they need done to it (web files, ASP.NET apps, .NET apps, SQL scripts, MSMQ queue creations, etc...).

We want to move away from the developer needing to specify this everytime- just set it up once, and then let Finalbuilder use the information to do the builds/ deployments when the objects need to move.

I am struggling with where to put this info and want to know how other places do it, what works, etc. I've designed an elaborate database for storing it (kind of a medadata database), but it just seems too complex. I've thought about storing it in text files and storing them in the SCM repository, but am not sure if that's the right way to go either.

It seems like we need instructions for both builds and deployments. These are the kinds of questions the instructions need to answer:
Builds:
Where is the project in the SCM repository?
What is the name of the object?
What are my dependencies/ references?
What unit tests are associated with this object?
Is this object COM or .NET?

Deployments:
To which servers am I deployed?
Do any services need to stopped for me to be deployed?
Do I need to be GAC'd? Registered? REGASM'd?
If I am an ASP.NET project what is my app pool?

Also- for doing automated builds, do most people have a separate FB project for each binary in their application? We have hundreds of binaries, so I am not sure how we would manage that. Do you store the FB project alongside the code in the SCM?

I appreaciate any feedback on this thread. These questions have been nagging at me for the last 4 years, but now I am getting very close to the point where I am able to make this change happen.

Owen

 

2

Hello Owen,

I am not sure, if I understand you correctly, but your developers builds the binaries of the product and the deployment is made by collecting this binaries with FinalBuilder?

We work in a different way. The FinalBuilder project performs the whole build procedure on a production PC. The sourcecode is automatically downloaded from a svn repository. The developers don't use finalbuilder on their PCs. They just commit the sorce code into svn.

Every part of the software is compiled in the FinalBuilde project. The sort order is defined by the FinalBuilder project. So every referenced file will be created before it is used by the next projekt. This is very important in case of COM (Active-X) dll files. All references between the binaries are stored in the Visual Studio project files.

After the building process we use a setup tool (Advanced Installer) for creating a Setup for deployment. We have the enterprise version of the Advanced Installer. It is working very well.

We use an own FinalBuilder project file for every product (not for every binary!). The FB project file of our main product contains 484 Final Builder actions including 39 Actions which are called in different loops (calling an obfuscator on every created .net binary). Every change on this FB project file is stored in the svn repository, too.

Perhaps this information is helpful for you.

Kind reards from Germany

Christof Konstantinopoulos,
Developer of GLM-Lasermesstechnik GmbH

3

Hi Owen, Just to give you an idea, here's how we're set up at VSoft:

  • For each product, we have a 'bootstrap' FinalBuilder project that does a 'get' from source control, then runs the actual build project using the Include Project action. This allows us to have the build project version controlled, right along side the rest of our code base
  • The build project builds all of the executables related to a product, runs unit tests, obsfucates and signs the assemblies and based on the project config, deploys them to the appropriate place
  • We use FinalBuilder Server as our CI server (obviously): when code is checked in, it runs the build using FBServer variables to pass in the default config options to the FinalBuilder project (ie, deploy to test)
  • When we want to deploy to prod, we go to the FBServer UI and run a build. We're prompted for values for the FBServer variables, which determine if its a test or prod deployment

There's no reason you can't do all this from FinalBuilder without FBServer - just by prompting for config values when the project runs. However having a single CI/build server has many benefits:

  • the build environment is the same for each build
  • you're not tying up your devs' machines
  • everyone can see which builds are passing and failing, get the last good build etc.
  • all the other code quality benefits that come from CI

Hope that helps.

Ben