"non string" category NUnit tests

Didn't feel very "clean" about [Category("MyCategory")] peppered throughout the code base.  This makes me feel a little better, though I wish I could easily apply the category attribute to an entire assembly.

"Productivity power tools" allowed for the pretty paste from visual studio

    // Haven't figured out how to apply to assembly correctly, but added it as a flag in my base anyway
    [AttributeUsage(AttributeTargets.Assembly | AttributeTargets.Class | AttributeTargets.Method)]
    public class BaseCategoryAttribute : CategoryAttribute { }
 
    public class FastIntegrationTestAttribute : BaseCategoryAttribute { }
    public class LongRunningIntegrationTestAttribute : BaseCategoryAttribute { }
    public class UnitTestAttribute : BaseCategoryAttribute { }
    public class CoreTestAttribute : BaseCategoryAttribute { }
 
    [TestFixture, UnitTest, CoreTest]
    public class SomeClassTests
    {
        // This test has categories TestFixture, UnitTest, CoreTest
        [Test, CoreTest]
        public void ShouldDoSomething()
        {
        }
    }

And it's like... what's the deal with build servers?

So what is a build server?

The simplest way I can think of to explain a build server is to imagine hiring a brand new developer for each code check in, giving them explicit instructions to accomplish the build, and letting them go.  Maybe that requires a bit of explanation - the idea of a build server is to provide a reproducible set of instructions/steps to accomplish building your application from start to finish without requiring additional input from the developer checking in the code.

Why do I need one?

As a developer without a build server, you might be in a situation where you have a project that builds perfectly fine locally, but when another developer attempts to build your latest bits, you encounter compile errors as far as the eyes can see. I unfortunately have experienced such a situation for each project I have pulled from source control (in instances where a build server was not used) - not that I fault the organization, persons, or projects involved - if you don't know better, you don't know better.

Once you do know about build servers, I do feel it is important to implement one if at all possible, as they are relatively easy to configure, and once done, an inordinate amount of time can be saved across developers.

Why doesn't everyone use a build server?

I only really see two reasons to not utilize a build server... and one is more of an excuse than a reason.  The first reason was mentioned above, if you don't know about a build server process, then you likely wouldn't have one.  The second reason (the excuse) - would be thinking it's "too hard" or "not worth it" to set up.  If the build server is too hard to set up, that likely means your manual build process is quite complex, and could likely benefit *more* from a build server than a simple application.  If grabbing a project from source control for the first time gives you a nice 10-15+ errors, which can take anywhere from 5 minutes, to several hours to resolve - and involve several developers - then you really need to think about what needs to be changed in order to fix that.  

Are there external libraries being utilized that need to be added to source?  Are there several SDKs missing from the developers machine required to build?  Did I miss something in check in that would not allow the next developer to build? All of those questions can be quite difficult to deduce when building locally.  With a build server, it's like a *separate* developer working on a project for the first time, every time, at every check in.  

If some new dependency is added to the project and is missed in the check in, the build server will immediately report failure and the developer (could) be notified as such, and actions can be taken to correct.  Without a build server, it could be quite the mystery as to why a project all of a sudden won't build, or why a project will not build for the first time.  

So why don't you have a build server yet?  

How do I set one up?

There are lots of tutorials on ( setting up build servers, and there are lots of build servers even! The build server I use on my personal site is TFS Build Service/MS Build I think the tutorial I referenced was: https://msdn.microsoft.com/en-us/library/ms181712.aspx

Other build servers include (but are not limited too):

Bamboo (https://www.atlassian.com/software/bamboo)

TeamCity (https://www.jetbrains.com/teamcity/)

ANT (http://ant.apache.org/)

GRUNT (http://gruntjs.com/)

etc

What's next? What else can I do with a build server?

Having a build server gets you and/or your organization a lot of benefit, but in my opinion, one of the best benefits is the ability to implement automated deployment.  Once a build is completed, steps can be taken in a number of ways which can vary greatly dependent on project complexity, your project's bits can be deployed to your next environment, AUTOMAGICALLY.

Flex "Global" RSLs

I am looking into deploying our custom libraries in flex in a "Global RSL Library" fashion.  I'm not sure how exactly to describe what we're trying to do but I'm going to give it a shot.

In every example I've found thus far, when using RSLs, the path specified at compilation is either:
1) Relative to the deployment path of the application (swf)
2) An absolute path.

Due to our development process and site layout, neither of these above methods of using an RSL is ideal.  What I am hoping to find a solution for, is specifying a relative path for an RSL in relation to the web root.

e.g. if I specify /libs/rsl.swf as my path, when launching my swf located at http://192.168.1.50/someDirectory/someOtherDirectory/project.swf the swf will access the RSL at location http://192.168.1.50/libs/rsl.swf

The problem we are trying to avoid in option 1 is that our swf files are located in varying directories all over our site, and to have duplicate copies of the libraries all over is redundant, and makes updates to our libraries more difficult as we have to make sure to deploy in every path where the RSL exists.

Option 2 (Absolute path) does not work especially well either in that our code is tested and QAd in varying environments (but only compiled once in our dev environment) - so specifying our absolute production RSL URL in addition failover URLs for every environment prior to production has a very high margin for error, and as far as I can tell, compile options are not something that can be reviewed in our QA process (to ensure that the developer [me] put in the correct production RSL path)

Is what am I attempting to accomplish understood?  I cannot be the first person that has wanted to be able to do something like this, have I simply overlooked the solution on the interweb?

- Kritner