Tuesday 8 April 2014

Continous Integration and Continous Delivery - Pitfall pattern when building and deploying software for the enterprise

Part 8: A conclusion

I can conclude 2 important points:

  • You have to be very much aware of what you are doing with your CI/CD setup and treat it as if it was a piece of the most important software in your business using all your favourite software principles when building/configuring your CI/CD pipelines.
    • This will enable you to focus more on business software.
    • It will empower all the developers and ops guys
    • And it will help you avoid having hired a guy name Jack, which most likely will be a very stressed out guy within a couple of years.
  • Finally you have to be very critical when choosing tools. There are many gold-plated solutions which will be your own downfall, like TeamCity/CruiseControl/etc.
Hang in there, in the future it will be al lot easier and remember today there are already an abundance of cloud services out there that will help set you free :).


Continous Integration and Continous Delivery - Pitfall pattern when building and deploying software for the enterprise

Part 7: My current approach

Right now we are in a transition phase, with a new setup, which we will probably change until the day our company ceases to exists, but there are major groundbreaking changes here which have and will change our daily work immensely.
  • Source control
    • Git (on GitHub), every other SCC I've tried (SVN/VSS/Mercurial) are nothing i mean nothing compared to Git.
  • Build domain
    • AppVeyor (have a look at TravisCI if you're not on Microsoft) (I will never go back to TeamCity, ever). AppVeyor is the ONLY product I could find offering platform independency via clear text configuration in your own repo. Seriously, ANY developer at my work can configure a complete build setup (build, test and package) within minutes. Disregarding PaaS services like AppHarbor/Heroku/Azure/other, NO ONE else can do that. PaaS is different story since everything is hosted in the cloud and that is not always an option for an enterprise setup.
  • Deployment domain
    • Octopus Deploy
    • Unfortunately there are not many tools like this for the Microsoft platform. Octopus is new and lacking basics things like WebHooks and platform independency. But its the best i have been able to find so far.
    • AppVeyor is also offering a deployment option, I just hope its a completely separate product so they do not mix up the domains like all the others. This option is still to new and lacks some of the great concepts which are available in Octopus Deploy.
  • Provisioning (only a work in progress at our company)
    • Puppet/Chef/Vagrant/DesiredStateConfiguration
    • Puppet/Chef both lack a lot of support for Microsoft. But that is due to the nature of Microsoft. Microsoft tends to be complicated and well, not very well thought off. But Microsoft themselves is starting to open the doors with DSC among things such as support for Chef/Puppet on Azure.
    • DesiredStateConfiguration is so new and given Microsoft very bad reputation for making life easy for us, it will probably be a while until its mature enough for serious use.
    • The thing about provisioning on MS is that its a bit grey where the provisioning domain starts and where the application domain starts. But thats a story for another time.
  • Workflow integration
    • AgileZen (is missing web hooks)
    • Custom plugins for AgileZen and GitHub
    • Custom webhooks for triggering Octopus deployments
    • Slack (has integrations for just about everything)
  • Server setup
    • Manly private cloud, working towards moving the majority of the apps into the cloud. Some apps allready on Heroku and some on AppHarbor.
Next: Part 8: A conclusion

Continous Integration and Continous Delivery - Pitfall pattern when building and deploying software for the enterprise

Part 6: How to avoid the pitfall

So, how do we get there and avoid falling into the pit?
Well it all depends on your current context.
There are tools that will help you get on the right track, but make no mistake you have to understand the domains and you have to invest time and resources into the subjects.
But remember these are YOUR domains not business domains, no one knows them better than you. In other words you have the best odds you most likely will ever have of succeeding with your project.
Keeping that in mind you have a chance of choosing the right approach and tools for your context. Understanding the domains and following common software development principles will help you to avoid making a big mess of things. 
But you still have to do a lot of work manually like scripting and server provisioning to get to the sweet spot, since the technology is simply not there yet (not for Microsoft anyway). 
But maybe in a decade or so, with a little help from the ever innovation cloud, we will be able to use 99% of our time studying the business domains and writing clean code, committing it to Git and be close to done. The rest will be automated.

All I can do now is point out some guiding bullet points of what to avoid and what to embrace. Its more or less a summery of all the previous posts: 

Things to embrace:

  • Know your domain(s).
  • Understand basic CI/CD, before you begin.
  • Keep the build and deploy domains separated.
  • Stick to the "One unit of deployment" strategy.
    • If you are stuck with old monolith software and can't see how to get started with CI/CD. Then break the monolith into small units of deployments, in separate repositories and have separate builds configured. This way you can one by one, migrate your apps to their prober domains and get closer to the sweet spot where its also possible to do refactorings (this is not an easy task mind you).
  • Don't choose the tools which tells you they can do both build and deploy in one. Gold plated tools are a lie in the majority of cases.
  • It should be easy to setup an automated build, it should not take more than a couple of minutes.
  • It should be easy to setup an automated deployment, it should not take more than an hour or so to get up and running with the first deployment . 
  • All developers should be capable of setting up both build and deploy for an application, as states above.
  • All developers should be DevOps people, there's no way around this one, software is complex and developers have to understand the entire process.
  • Trust you developers and ops people, empower them to do everything and to communicate with each other.
  • Choose tools you kids could configure (such as TravisCI or AppVeyor in the case of CI . This gives you minimum maintenance and allows other people to help advance the entire process with better and more innovative ideas than you could ever think of.
  • If you can use hosted services like GitHubAppVeyor / TravisCI / others which do not binds you to their platform, do it. They are experts and will do everything possible to keep their services running, unlike you and your Ops team which most likely will have a hard time explaining/convincing the importance to the business.
    • Services like AppVeyor/TravisCI allows you to add your setup to your own source control in a human readable format. This removes the black magic and pain that most tools for CI/CD out there have, making you and your software easy portable.
  • Never compromise with the quality of your setups and custom integrations (apps/hooks/scripts/etc). 
    • Follow common software development principles and use BDD/SBE/TDD/DDD/NDD if possible for your integrations to ensure that the next guy has a chance to understand your intentions.
    • Let the tests be the documentation, do not start a big word document or a soon to be outdated wiki page.
    • Automate everything, BDD/SBE/TDD/DDD/NDD style, from setting up a new developer at the company, to deploying your applications.
    • Do not hide processes, let them be expressed in tests.
  • Review every single integration as you do with business software.
    • When you have a new integration you think is good and when you think you have gotten it right, get someone to set you straight.
  • Consider using some sort of provisioning tools (it could be simple deploy scripts) to allow easy migration and setup of new servers. Ideally this will take you down the path where it is possible for you to create genuine Phoenix servers and take a load of burdens from the Ops people.
  • If you haven't done ANY CI/CD before, do not wait. Jump right in, I dare you. If you choose some of the newer tools around, talk with your colleagues about the CI/CD terms and read this post (and others) a couple of times, you should have a good base for starting. CI/CD gives tremendous value and ensures quality and there a an abundance of sources out on the net.
  • You know you have done good with CI/CD the minute you’re expendable and everyone can do CI/CD.

Things which signals danger and should be avoided:

  • If you have 1 guy, Jack, maintaining and evolving your local CI/CD
  • If anything in your CI/CD setups is complicated, something is wrong. Go back and redo from scratch. Do not hack or bend it unless you understand the consequences and know that the next guy can live with it.
  • If you are using your build server for anything other than building, running tests and packaging software, then you are messing with the domains and others will have a hard time to figure out what the hell you where trying to do. You are abusing the technology.
  • If you are using your deployment tool for anything other than deploying software, then you are messing with the domains and others will have a hard time to figure out what the hell you where trying to do. You are abusing the technology.
  • If the CI/CD tools has features which allows you to do stuff that is outside their domain, don't use the features or better yet change tool.
  • If you spend time maintaining build servers / agent
    • If you are installing/reinstalling software often (Visual Studio, Git, databases)
    • If you need to configuring SSH keys on the build servers
    • If you need to configuring remote access on the build servers
    • If you have resource issues on build servers (to few build agents)
    • If your build server has frequent failures
    • If your build server uses global admin accounts for doing stuff
  • If you have "it works on my machine" discussions with developers
    • If you have a good setup, then the developers will figure out the issue themselves and you should not hit this classic issue.
  • If you are buying new versions of a tool which makes you ask a question like "do I dare to upgrade... Better do it in a weekend..."
    • If you are scared of upgrading, then you should use another tool.
    • Upgrading tools is maintenance and thats bad. Cloud services often handle this for you and are subscription based.
  • If you are reconfiguring setups over and over again due to trouble with  simple concepts (like branches) that you think you understand, but the tool have strange if not directly illogical implementations of the concept.
    • Try explaining how to setup a prober dependency chain in TeamCity to a new developer... good luck
    • Or try configuring a personal build using templates and GitHub in TeamCity.
  • If you struggle over and over again with scripts for doing simple deployments to MS.
    • This is often partially due to Microsoft have made some very, very poor implementations. Edge case services start/stop is an example of this.
    • The other reason is often that you are using custom scripts in perl/bash/powershell/C# which are NOT covered by tests.
These are all signs of trouble which you should take very swift action with the second you spot and understand them or else they might haunt you and your company for years to come.

NB:
Any tool I have favoured in this post should not be used unless you have studied them in relation to your own context first.

Next: Part 7: My current approach

Continous Integration and Continous Delivery - Pitfall pattern when building and deploying software for the enterprise

Part 5: A real life example of how simple it should be

Im not trying to bad mouth what a lot of people out there are doing, I'm trying to wake them up.
Rattle their cage.

There are alternatives to overly complex CI/CD setups and I would like to share a ground breaking experience I had when I recently demo'ed the first part of my new take on CI/CD for my colleagues.

I have used TeamCity for years. Never once, NOT EVEN ONCE, have a fellow developer asked me a question that contains even a fraction of the following statement:
Wow, that TeamCity stuff looks easy. Can you give me a 5 minute tour or a link so I can get up and running with this great new idea I have?
But guess what, when I did the demo of our new setup with a cloud build service, 1 guy actually disrupted the demo to ask me the following question:
Wow, that looks easy and cool. Can you give me a login so I can get started right away?
A week later another developer asked the same question (more or less). Now i get more time to do actual business development.

The beauty of the cloud service we are using is that it enables us to setup a build in 20 lines of simple, readable text, which is stored besides our solution file in raw text. This almost makes us independent of the cloud service as we have the build configuration under version control.

This story says it all.
Configuring a build should be this simple and in the future it will get even simpler, just take a look at some of the PaaS's out there. But with current, old technologies, such as locally maintained build servers, you are stuck with a guy called Jack and developers who won't get involved very often. Things will break and hurt more.

The real and absurd truth hidden in this little story is that finally the build domain appears to be simple enough that the domain experts themselves understands it. This is NOT the case with tools like TeamCity.

Imagine if that happened with your business apps...

Next: Part 6: How to avoid the pitfall

Continous Integration and Continous Delivery - Pitfall pattern when building and deploying software for the enterprise

Part 4: Bloated Tooling

For the last several years I have been using tools like TeamCity for doing most of the CI/CD at the places I've worked. TeamCity was a revolution for me, coming from CruiseControl and I've been a very enthusiastic JetBrains fan for many years. My closet counts some 13-15 jet brains t-shirts (R#, TeamCity) :).
I used to love TeamCity. It could do everything. Yes everything!
Man, I could:
  • build software
  • run scripts
  • send emails
  • provision servers
  • create databases / infrastructure
  • deploy binaries all over the place
  • just about everything could be automated...
Wait a minute that’s bad, very bad.
Nothing should do everything!
That's making a mess of the domains, treating them as if they were one.
Would you like to have just one application running all of you 100+ business apps, in sort of a "complete integration pattern"? 

No way! That's an anti pattern.
As I emphasised in my previous posts the build server should control one domain only, the build domain.
This domain has 3 major responsibilities/subdomains:

  • Build the software
  • Run the tests / verify the quality of the software
  • Package the software
Nothing more.
It certainly should NOT deploy your software and most definitely NOT run trivial tasks such a creating databases for testing, function as a scheduler for repetitive tasks or as an notification hub for the entire company.

In this same manner your deployment technology of choice, should also have one conceptual responsibility: Deploying packages.

But for some reason most of the tools I’ve seen are all Swiss Army Knife inspired tools. They have been designed to perform way, way, way too many different and complex tasks.
This is the number one mistake i’ve done and the number one mistake i see people do over and over again. Put everything into the build/deploy tool!
However its hard to blame people as tools like TeamCity are bloated with cool features, which allows, if not inspires to abuse. 
They are over engineered and as if that was not enough, there are 100's of post on the net with people showing off just how much they can bend/exploit the tools, not realising that they are hurting themselves.

Developer's tends not to question the many capabilities of a tool, instead it's often a selling point:

See here boss, if we buy TeamCity we also have the option to use it as a task scheduler for doing trivial ops tasks + we could write some scripts and let it deploy our software. Ohh and with this custom plugin we can also use it as minor ticket system which we could bend a little for our own local work processes...
By now I hope that you can agree upon or at least be open to the following statement:
Building and Deploying software are 2 completely different things that has next to nothing to do with each other, besides the package contract.
And contemplate this for a moment:
  • It should not be hard to build software
  • It should not be hard to deploy software (thank you Microsoft…)
Gold plated tools are by far one the biggest downfalls we have pushed upon ourself as a community.
No single tool can or should handle all the requirements across all companies, countries, transcending law, etc. At least not until we are one united planet, with one conscious master mind...


But we always seem to seek that perfect fit, which promises to solve all our problems and when we get into trouble with the chosen path, we tend to bend the rules we have, instead of contemplating the domains:

  • Should this be refactored?
  • Are we crossing a domain boundary?
  • Is this actually a new domain?
  • Is this the right tool?
  • Do we even need a tool?
Bloated tooling is bad, avoid it. Building and deploying software should not be hard. 
For example configuring a build should not take more than a couple of minutes and it should not create a hard binding to a tool.
TeamCity/CruiseControl .Net are good examples of tools which offer to many capabilities, binds you to their platform and are way to complex to configure. On the side they also force you to do a ton of manual maintenance (build agents, visual studio, new versions, etc) that will keep you from developing new business software, as it is very time consuming and most likely will get you more and more frustrated over time.
If you claim that you need these kind of tools because you are developing highly complex software. Then my answer will be: Then there is something wrong with your software or the way you are developing the software. Keep it simple.
You end up with a guy named Jack, if you are not extremely careful.

On the other hand, if your name is Jack, you might have a job guaranteed. That is until the day a guy like me gets hired and starts asking questions :).

Next: Part 5: A real life example of simple it should be

Continous Integration and Continous Delivery - Pitfall pattern when building and deploying software for the enterprise

Part 3: Root Causes

So what went wrong with the setup Jack put together before he quit?

  • Misconceptions about CI/CD?
  • Lack of domain understanding?
  • Poor tooling?
  • Mischief?
  • Complex software?
  • Bureaucracy?
I don't have an answer, it always depends on the context in which you are working.
But I have been a "Jack" for many years and I have seen a lot of "Jack's" around. All great, intelligent colleagues which I admire for various reasons.

In my time as "Jack" I have spotted 2 things which all of these guys, including myself, did wrong:
  1. Lack of domain separation and understanding, see my previous post.
  2. Bad/misguided tooling or wrong use of tooling
In my next post i will elaborate on what i mean with misguided tooling.

Next: Part 4: Bloated Tooling



Continous Integration and Continous Delivery - Pitfall pattern when building and deploying software for the enterprise

Part 2: The Domains

The problematic pattern described in my previous post is more or less the same pattern you see when a code base is not probably maintained and refactored over time. 
It becomes, bighugeugly and utterly complex making every new feature, bug fix, refactor or tweak a combined effort between multiple individuals and the process spawns weeks of implementation and testing, instead of hours. Always with a lot of bugs even though you use TDD/BDD/DDD/SBE/NDD etc.
And just think about how hard it is for new developers to get up to speed on systems like this.
So whats wrong?
Well, likely you have a flawed design/architecture which means you misunderstood the domain(s) or due to ridiculous deadlines, “I never had time to do refactoring” (shame on you) you skipped the much needed refactorings. Maybe you’ve just been on leave for 6 months and come back to find your nicely separated domains completely mutilated by developers who had no understanding of the domains and thought interprocess communication via email combined with direct access to a shared database was the best idea ever…
Anyway, you have a problem when Jack leaves the company and its a big problem.
My point is that you must regard your CI/CD pipelines as if they were individual pieces of highly complex software. Because they are.
This means that your build and deploy processes adhere to the exact same principles as are commonly considered good software architecture and design.
This is basic stuff that is extremely hard to achieve.
  • It requires tons of domain experience (dev/ops)
  • It requires the involvement of many people or at least a couple of individuals with way above normal intelligence to get it even remotely right and you do not have many of those around
  • It can almost never be handled successfully by just 1 guy, like Jack
The place where people go wrong most of the time is, according to my own observations, with understanding that there are multiple domains when talking about CI/CD. On a larger scale i will claim that:
  • The build process is one domain
  • The deploy process is one domain
  • These domains have nothing in common except a simple package contract
So with your CI/CD process, uses the same principles as you would with business software. To mention some of my favourites:
  • Spot the domains
  • Understand the domains
  • Separate the domains
  • Spot the subdomains
  • Use SOC and SRP but on your subdomains, adjust
  • SOLID
  • TDD
  • BDD
  • DDD
  • SBE
  • NDD
  • MSA (bad name imho, should be something with domains/subdomains instead, so developers are lead to think about the business and not the technical solution)
  • etc.
  • Whatever combination works for you :)
Remember when talking about CI/CD you are actually in YOUR OWN DOMAIN, no one knows these domains better than you and these are the domains that enable you to move securely and fast when developing software.

It's a must to understand, separate and continuos improve upon these domains.

Next: Part 3: Root Causes

Continous Integration and Continous Delivery - Pitfall pattern when building and deploying software for the enterprise

Part 1: The Problem 

I’ve been working with CI and CD for some years now, in the context of building and delivering enterprise software for the financial and telco industries. During these years i've seen a "less than ideal" pattern repeat itself. 

The pattern starts with identifying one amazing individual in the company. 
This guy, lets call him Jack (Jack Of All Trades, no similarities intended) is your average dedicated developer, but with a touch of flaming dedication and curiosity. 
Jack is also an Ops guy, mainly due to his great curiosity and sometimes he is actually able to teach your Ops team a few things. 
So Jack is a DevOps guy. 
On a lucky day Jack spends as much as 25% of his time developing business software and the other 75% automating/maintaining the company’s CI/CD pipelines. 
Think of Jack as the transition between you and the DevOps people we will all become somewhere in promising the future. 

You might already have spotted the problem here. Jack is a great guy, he’s a DevOps guy, so he takes responsibility for and understands the whole software delivery process, which is a good thing. 
But he is most likely the only one at your company. Jack knows about: 
  • environments
  • servers
  • firewalls
  • DNS
  • load balancer
  • cloud stuff
  • CI/CD
  • compilers
  • frameworks
  • strange quirks of Microsoft, etc. 
Jack is a key individual even though he has automated just about every aspect of building and deploying software in your company. 
The Ops people love him because finally there's a developer who understands some of the pains they have to work with on the MS platform.
The other developers finds his tasks uninteresting or scary, but they are extremely dependent on his skills and work, every single day

So to be clear, the problem here is you have Jack, one guy, configuring, maintaining and advancing the whole CI/CD process, more or less alone. 
What do you do when this guy quits?
Despite all Jack's best efforts to automate everything he touches, he is now the ONLY one who really knows how the automation and CI/CD processes works in the company. Everybody loves his work as it makes they're day less painful and most have good suggestions for things that could be even better. However, no one but Jack possesses the knowledge to understand the complexity of the systems/pipelines/toolchains he maintains. 
Originally all Jack really wanted, was more time to develop and less time building/deploying, since these are both very error prone processes. Now he finds that his CI/CD work has taken over his main function, which was developing business software. 
So now he quits. 
Leaving behind a couple of 100 scripts, 100 repos, different build setups (your company has some 100+ different apps), different technologies such as bash scripts, powershell, cmd, TeamCity, CruiseControl, integration services, etc, all configured by him and probably a good many servers with dedicated users (with specific rights of course) and specific setups which needs to be maintained (new version of Visual Studio, TeamCity/CruiseControl, service packs, databases, etc). 
Maybe he even did a few writings in the company wiki on how the setup works, but come on, who in their right mind can document a complex setup like that. The wise guys scripts it, but there's bound to be gaps as the domains are simply to big for just one guy, Jack. 
Boom!
Now you wish that every developer had better understanding of what DevOps is about and were capable of taking responsibility for the entire software delivery process from idea, to implementation, to build, to deploy, to test, to staging, to production, to monitoring, etc. 

But they don't, at least not yet, and you're screwed, or at best one of the other developers is screwed and needs to immediately start understand the work that the guy did over the last 3 years. 
Ultimately this could lead to frustration and more developers quit.
You are left at dangerous crossroad of just keeping everything running vs. investing heavily in the CI/CD setup (again) which will cost you money right here, right now. 
Seriously, people does this all the time...

Next: Part 2: The Domains

Continous Integration and Continous Delivery - Pitfall pattern when building and deploying software for the enterprise

Introduction

This post is the first in a small series touching on the subject of configuring and maintaining CI/CD in an enterprise. The series main goal is to help and entice people to look more critically on every single process they perform. 
I tend to obsess "a bit" about automation and can talk for hours on end so if you are just starting to realize why CI/CD are good ideas, I suggest you read up on these subjects first and then come back to read my posts. But read my posts BEFORE you start configuring your setup, just for inspiration. Please. 

Also, note that this series of posts is the product of me working mainly on the Microsoft platform. I know and dangle with Continuous Integration and Continuous Delivery (CI/CD) on other platforms in my spare time and most of them have WAY superior ways of handling CI/CD  But these posts are based on the Microsoft platform.

Next: Part 1: The Problem

Monday 7 April 2014

The Power Of AppVeyor - Build using the cloud

AppVeyor is a relatively new cloud service which provides:
  • Phoenix build server
  • Scalable build server
  • Private NuGet feeds
  • Deployment to Azure/Amazone/private cloud/etc much like Octopus Deploy.
  • Platform independence, through configuration that is kept in your own repository
Im currently using it to get rid of yesterdays technologies such as TeamCity / CruiseControl .Net which binds our company to their platform and require loads of maintenance. I writing a new post upon this subject, so stay tuned, it should be out in a couple of days :).

AppVeyor will lift the majority of the burden there is by having an on-premises build server. You still have to configure an image every once in a while for AppVeyor if you need complete control and the default image is not good enough, but thats about it and then you have a scalable build server environment consisting of beautiful Phoenix servers.
The Phoenix servers will help you ensure that you know what is actually going on when stuff stops working. Unlike their counterpart Snowflake servers which over time becomes a horrible mess and unrealiable.

Try installing a new version of Visual Studio across 9 build servers, manually (if you lack provisioning as is common for MS) or try setting up SSH keys for TeamCity manually across the same 9 servers because you have a new colleague. Or hey, maybe try rebooting your build server, our old TeamCity server have failed to start on 2 occasions within the last 6 month and it was a simple reboot, no updates or anything.
See stuff like that sucks and ends up in tedious, manual work.

With services such as AppVeyor  you don't have the same amount of issues since you are using Phoenix servers and when it comes the initial setup AppVeyor handles all ssh/keys, branch builds, etc. for you as long as you just supply a GitHub account. Now since its a cloud service that means it has a team of employers dedicated to keeping their service running and the money flowing or else they are out of a job.
This is a good thing since it means that they're main concern is keeping the service running and evolving. This allows you to focus developing business application instead of maintaining a build server.
Thats a major win for most enterprices.

The biggest power of AppVeyor is its use of yml. Yml is a simple text format with which you can define a build. For ex:

  os: Windows Server 2012

  services:
    - mssql2012sp1

  assembly_info:
    patch: true
    file: AssemblyInfo.*
    assembly_version: "1.0.1.{build}"
    assembly_file_version: "{version}"
    assembly_informational_version: "{version}"

  platform: Any CPU
  configuration: Debug

  before_build:
    - nuget restore

  build:
    project: MySolution.sln
    publish_nuget: true

  test:
    assemblies:
      - MyTests.dll
  artifacts:
    - path: MyApplication\*.nupkg



In 21 lines I have described a complete build, run tests, package and publish setup. This is a text file i stick into my git repository and I'm done. No more configuring needed, AppVeyor does the rest.
Versioned build configuration,  means next to no hard dependency on the service, nice :).

AppVeyor has borrowed this concept from TravisCI and thanks heaven for that :).
Its simple, its ingenious.
It will empowered the developers to do the stuff that one guy normally takes ages to configure in TeamCity.
Finally setting up a build takes less than 5 minutes and everyone can do it. :)

With this feature AppVeyor completely blows away other services and tools for the enterprise, such as:
There are of course PaaS's such as AppHarbor or Azure for MS, but they have their limitations and are aimed at also hosting the applications. AppVeyor offers a platform independent service which saves the enterprise loads of manual, tedious and error prone work. A beautiful, simple, liberating first step into the advantages of the cloud. 

If you are working in one of those companies who have a privately maintained build server which tends to occupy a least one person every day, then you should seriously consider using a cloud service such as AppVeyor and free some vital resources at your company.

AppVeyor is still new, but have many things in the pipeline for the year to come that will also make it a serious competitor to Octopus Deploy. I just hope they don't get swiped up by MS or some other giant company who will let their service decline.

Locally maintained build servers, is about to become a thing of the past. :)