We recently cohosted a Webinar on Lean processes with our friends from AccuRev. Analysts from Forrester discussed trends in the market, and how companies are applying Lean principals to find efficiencies in their development and release efforts. The webinar was fantastic and we had more questions than we could get to live. Here are some of the questions that came back in to us that we wanted to answer or expand on.

Q: Setting up all that automation seems pretty intimidating when in the throes of projects.  How much setup time is usually required for a standard .Net/Windows environment?

A: Automating does require effort. However, usually when the team has a little while to breath it can dedicate someone to automate the parts of their process that are the most wasteful. Once that's done, the time that was spent on those processes, can be fed back into the automation loop to build out a robust system. Usually teams can get some benefit back after a couple weeks (sometimes a couple hours) that can start this cycle.

Q: Is the tool set development platform independent - Java and/or .NET? 

A: Enterprise tools like AnthillPro have to work across Java, .Net and native languages. Many large, mature companies will have a little bit of everything going on. As you drill down towards things like IDEs, yes the toolsets will need to be language specific. From a lifecycle management point of view, some language specific features can help, but the core engine should be kept language agnostic.

Q: Many of the features that you mentioned are also offered by other tools such as Hudson, CCNet in the open source side and TeamCity, Bamboo in the commercial side... What is it that your tool provides that sets it appart from the competition?

A:There are a couple of big differences. The work-group level CI tools aren't really competitors. We participate in the enterprise space which tends to require more security, scalability, etc than tools like CCNet, Hudson or Bamboo are concerned with.

Unlike any of the tools you listed, AnthillPro has a real focus on the release pipeline and tracing everything that happens to single build from the time it's created, through deployments to various environments, automated and manual testing and finally release. Where standard continuous integration is concerned with what happens at build time, AnthillPro tracks a build's progress for days, weeks and even years. There are a number of features that support this, an example of which would be an embedded artifact repository. This stores the build artifacts for use by other builds, or to feed into secondary processes like tests or deployments.

Q: Does AnthillPro version the build artifacts itself or does it pass that onto the SCM system?

A: AnthillPro actually ships with an embedded artifact repository called CodeStation. So it versions build artifacts and discards them based on customer rules. SCM systems tend to be optimized for text files accessed at the tip of a branch, a seperate artifact repository can be quite helpful.

Q: Agile, multi-stage CI, massive parallelism will quickly exceed bulid and testing resources.  This is good in that dev/test is productive but the infrastructure probably can't keep up. Comments or suggestions?

A: In general, I'd argue that small improvements in dev/test productivity pays for an investment in additional hardware pretty quickly. With limited hardware, the team can make due by backing off the continuous nature a bit. Perhaps hourly builds instead of builds every five minutes. For tests, non-continuousness is very normal. What I want out of my "continuous tests" is a fast set of tests that gives me some confidence that the system isn't a complete disaster - by further integrating I won't risk too much of my fellow developers' time. Slower, more throurough test cycles may be run daily - or in the case of some stress tests weekly - to detect less severe regression problems.

Q: Are you seeing this trend in Agile development in PRODUCT companies (where software developers are building products for a product company) versus IT organizations (who are building "products" in support of their business (for instance, a financial institution or pharma company)?

A: Like the team from Forrester, we've seen product companies as the early adopters here. However, Agile and Lean processes are now well into the mainstream. From the corporate IT side, we see increasing adoption as teams find that they can deliver faster with more reliability. While a high percentage of projects still fail, Agile does help teams fail faster lowering the risk of launching a new project. Lean processes are helping organizations lower the costs of updating and maintaining existing applications as well.

Q: Some IT Dev shops have not had the budget (or the maturity) to have all the standard environments between Dev and Prod. Please provide some insight into use of AnthillPro where environments are combined (for example, Pre-Prod also doubles as emergency fix testing environment). What impact does that have on the continuous multi-stage integration premise for using AnthillPro?

A: In AnthillPro terms, you would create both Pre-Prod and Break Fix logical environments. Those logical environments would contain the same machines. Making sure Pre-Prod and Break Fix uses weren't stepping on each-other is often just handled socially where there's good communication amongst the team. Other strategies include clever locking where Pre-Prod can't be deployed to unless the most recent build to enter Break Fix has been marked as "Passed Break Fix" or something similar.

It's also not uncommon for the same physical machines to have two instances of the application running in different paths and ports. Taking this a step further,, we see teams set up these environments on virtual machines and use the AnthilllPro VMWare integrations to provision and decommission VMs as required. Few of us have all the hardware we want, but there are a number of strategies for stretching the hardware you do have for multiple purposes within AnthillPro.