Speaking to a customer recently, I was told:

"Honestly, our favorite thing about moving to AnthillPro is that we've moved beyond 'Plug-n-Pray' deployments. You know, many of our deployments were so scary we'd have a bunch of people in the office or on a call all weekend to execute and debug the deployment and then have all hands on deck Monday morning to deal with the inevitable problems. We were all so stressed and tired that we were pretty much useless for a few days after the deployment.

That's all gone now that we've automated. Most of those deployments are a 30 minute effort Friday night, and we don't do anything special on Mondays."

It always feels great to hear that your product isn't just good for productivity, traceability, etc but that you're also making people's lives better by giving them their weekends back. But I think it's important to call out that changes in process for this customer and others like them that are equally important.

• No more Word documents containing the deployment plan They're hard to follow, and get out of date.
• No fixing application server configuration in Test environments by hand: Instead of fixing a broken configuration of the test environment by hand (which often results in the same breakage in Prod), the teams fix the automation to set to the configuration properly in all environments and redeploy to Test.
• Repeatable Deployments: An automation system can only deploy that which is automateable.  This rules out funky processes that rely on guess work and gut checks. The process of figuring out the deployment process well enough to automate it makes the process better. (see our WebCast on using automation to shine a light on your process.

It comes down to making sure your process can be automated. Automating that process. And not circumventing the automation - even in test environments. Each of those three elements delivers some unique gains.

AnthillPro's integrated build artifact repository is one of our favorite things about the tool. After all, if you're going to support moving a build through it's lifecycle towards production with deployments and tests, it's helpful to manage the files that are "the build".

The repository is also hugely helpful for managing build time dependencies between projects. However, teams using Maven don't necessarily need a new repository and definitely don't want a new way of specifying dependencies.

Read on for how...

Read more...

Michael Sayko, a software configuration management consultant based in Austin, Texas, wrote a great article for CM Crossroads on the advantages of a build pipeline approach to build and deployment automation. You should check it out.

I'm a big fan of the pipeline metaphor, along with related concepts like continuous delivery and DevOps, it encourages the team to think about automation from build to production release. That said, it's important to note that the pipeline is really an idealized view of the world. Some builds will not go through their lifecycle by following the standard release pipeline. An emergency will require a rush that skips some testing environments or sign-offs, or after going to UAT, the build is re-deployed to QA to check something, or..., or..., or... - the real world collides with the plan.

A build pipeline is a good model for planning your automation, but make sure your implemented automation is ready to handle the real world along with the ideal case.

Last week Jeffery and presented BDTR Automation in the Enterprise where we discussed the drivers for expanding automation from the team level to the enterprise level, as well as the requisite technical and social components to the design and rollout of such a system. We had more questions than we could cover in the Q&A period. Below is a selection of the questions asked. I've taken the liberty of combining some related questions.
Q: If each team (or functional silo) has its own automation, do you suggest that a separate team own the glue processes that span those silos?
...

Read more...

In our webinar on Build-Deploy-Test-Release Automation in the Enterprise (replayable here), we observed that there are a number of questions that cut across teams. These are questions that we suggest than an enterprise system should be able to help with. A couple people asked for the list of questions we presented in the slides. Read on for the full list of questions...

Read more...

I was recently chastised in the comments for referring to "QA" as a group of people. The commenter fairly pointed out that quality improvements come from everyone who touches the software along the SDLC. While most of my customers do have a team called "QA", I couldn't agree more that quality improvement efforts need to be ever-present throughout the software development life-cycle.

A recent article by Capers Jones in InformationWeek drives this point home reviewing data from over 13,000 software projects:

To achieve a cumulative defect removal efficiency of 95%, it's necessary to apply at least nine defect removal activities in sequence:

1. Design inspections
2. Code inspections
3. Automated static analysis
4. Unit test
5. New function test
6. Regression test
7. Performance test
8. System test
9. External beta test

Requirements inspections, test case inspections, and specialized forms of testing (such as human factors, performance, and security testing) add to defect removal efficiency levels.

 

That's a lot to do, but it at least lines up with what we're seeing many of our customers working towards. There are numerous tests across the SDLC, and many of them can be automated. AnthillPro can make sure the tests get run, and aggregate the data together.

Unfortunately, the parts that can't be executed automatically - like code reviews and usability testing - tend to fall by the wayside as budgets are cut and time is short. Teams with a commitment to quality should work stick by these techniques and trust in a time return down the road due to fewer defects, happier customers and less rework.

A pattern we are increasingly seeing in our customers employ is on-demand testing environments using virtualization. These can take many forms and be accessible just to automation or face development and testing teams...

Read more...

Eric already mentioned Bola Rotibi's guest editorial in Issue 294 of SD Times in his blog entry on the Rise of QA, but there was another aspect of her article that resonated with me. She offered a compelling one sentence summary that captures the most common reasons our customers adopt AnthillPro:

This explains why, in the long run, automation will happen: to ensure compliance to rules and regulations, raise productivity, enable a high degree of transparency, and increase the speed of delivery.

The stereotype is that Agile and Audit belong in different camps. Agilists are painted as cowboys willing to overthrow all the established rules, damn the costs. The Audit/Governance/Compliance crowd are seen as hidebound, rule-bound, dinosaurs who care more about checklists than delivering value. But build & deployment automation has provided a common ground for these people. Automation is needed to keep up with the pace of agile delivery, and also provides a better audit trail than you have from the old system of manual process.

No wonder then that people in both camps can agree: Death to Manual Deployments!

The DevOps movement which has been doing hard work to break down silos, improve deployment quality and even push towards continuous production deployments has focused on improved cooperation and communication between developers and the system admins (operations) who deploy releases out into production.

Recently, I've been wondering, "Where's QA and test?" The DevOps community has put a lot of emphasis on automated testing, which is great, but I haven't heard a whole lot about where manual QA fits in.

Listening to Timothy Fitz from IMVU champion continuous production deployment at the recent Leaders of Agile virtual conference was a little reassuring. Even though IMVU automatically deploys most code changes that pass tests to production - deploying many times a day - there's still skilled, human testers involved. They test new functionality and features before those features are enabled and made visible to end users. So, QA and testers do have a place.

A aggressive view of the role of testers was presented by Bola Rotibi's in her editorial in SD Times, "Rise of the machines: Power brokers in DevOps bonding! While Ms. Rotibi's thesis was that communication and automation are key (and we love that), she explored QA's role as a conduit and facilitator between development and operations:
The line of communication between Dev and Ops needs to be clarified. Neither is well-versed in communicating what either needs to carry out their respective responsibilities. QA and testing, a group within the software delivery team, could and should help smooth the relations between the two sides.

Today, testing is seen as an extension of development rather than a core part of the deployment team. But QA and testing teams need to have a broader scope and a more active role in shaping and strengthening the DevOps relationship. Many of the management and monitoring tools are raising the profile and capability of the testing function as a key conduit between DevOps.

This strikes me as a critical step in the evolution of a traditional, siloed IT shop into one with stronger development to operations coordination, trust and cooperation. Even today, QA teams have many of the needs of development teams as well as operations. They have infinite work and need to move quickly and test new builds frequently. Their pace is closer to development's than operations. At the same time, if things aren't being installed properly in QA, if control is lacking, their work can be wasted. QA should be primed to lead Dev and Ops as they move forward with Agility and Control. What remains to be seen is if QA and test has the courage to embrace automation and enough respect from their partners in the IT organization to be able to lead.

Many of our customers had a CI tool before even looking at AnthillPro. In the past, they were primarily CruiseControl users. Today, most have Hudson and a few have a commercial CI tool like Bamboo or TeamCity. While some of these customers have since stopped using their old CI tool, others use both solutions in parallel.

On its face, this situation may seem strange. Hudson is a pretty good Continuous Integration server. Why reconfigure projects in AnthillPro? Why does a coexisting scenario make sense? This is post is dedicated to a quick look at why teams would switch to AnthillPro or use both.

Hudson: Continuous Builds Hudson is a CI server that can manage a build farm of one or more machines. It can poll source control and perform builds when there are changes or on regular schedules. When the build completes, it can notify interested users of the success or failure of that build. In other words, it's a modern continuous build server.

AnthillPro: Managing a build's release pipeline Teams using Hudson tend to turn to AnthillPro when the tool's audience expands beyond a development team looking for rapid feedback from builds and early tests. When the organization wants to manage the promotion of a build from test environment to test environment and finally to release, AnthillPro's build lifecycle management shines. AnthillPro features like clear delineation of environments are critical when deploying between environments, but can be overkill when just managing a build farm. Similarly, tight security is warranted when the tool may be used to deploy to production, but is less important for a build server.

Using Both Because AnthillPro is a great continuous build server in addition to being a deployment automation and release management solution, it can (and often does) replace Hudson. Why would some teams run with both tools? Simply, the developers are happy with Hudson and don't have a need to change. The release managers, or QA team, or operations guys need the AnthillPro magic and they implement it leaving the developers to their own devices. There's some duplication of work (which drives anti-waste people like me crazy) but everyone gets a tool that meets their needs without rocking the boat.

Simple post this afternoon. We're on Twitter.

You should follow us on twitter here.

If you've attended our webinars, seminars or CITCON you'll have heard me talking about how Agile software development should lead to more cooperation across functional areas, from development through to operations. In that vein I wanted to share this example from Chris Walquist of DRW who sent me a short story of effective pairing between services and development teams:
"Our team is a services team rather than a pure development team, so constant pairing is not the right answer. However, we've found that occasional pairing can be very efficient. If everything is already set up for pairing, it's much more likely to happen when it should.
"A developer, John, wanted to enhance his project's AHP [AnthillPro - ed.] deployment workflow with some server stop/start commands.  He knew where the scripts were and how to use them, I knew AHP, and we both knew our way around Linux and vi. I had my workspace already set up as a pairing station (2screens/keyboards/mice), which made it very easy to get going. John did logins & navigation, and I did the AHP job step setup. It was very natural for one of us to lean back from the keyboard as a signal that input was needed from the other. The whole exercise would have taken perhaps all day what with the impedance of emailing/chatting back and forth (we are on different floors). By pairing, we got it done in about 20 minutes."
There are several elements I like about this short story.

First the is the core cooperation between the services team and the development team instead of the development team just creating their own ad-hoc solution. As a result they now have a reusable enhancement that I'll bet will benefit other people down the road.

Second, there is the physical infrastructure in place to facilitate the interaction. The more I read about Lean Manufacturing / Software Development the more I appreciate that the output of a team is a function of the system they are working in, and having the pairing station in place was part of the system in place. I find it impressive that they have a pairing station to support occasional pairing.

Finally there is the realization that the cooperative pairing — while more disruptive at the moment — was a much more efficient way to get the job done than trying to multitask across floors with emails and instant messaging. That direct "let's get this done" approach is cultural and reflects a bias towards completion instead of (often illusory) "progress".

Recently, a couple customers asked me about the Relay Server option for AnthillPro. Since it seems to be something relatively unknown, I thought today's blog post could provide an overview.

The Relay Server has two main purposes
    ▪    Proxying agents behind a firewall
    ▪    Caching artifacts across the WAN

Read on for more on the Relay Server.

Read more...

The CI community has made plenty of compelling arguments that fast builds facilitate continuous integration. And by "fast" we mean the time it takes to get a cup of coffee or just at least  under 10 minutes.

But what do we do when the build (not the integration tests but compile and package) takes 30 minutes and produces large files? What if there are potentially hundreds of changes a day being introduced? Can we get some of the benefits of while keeping hardware and storage utilization in check? The short answer is "yes" for the full story, read on.

Read more...

Urbancode is pleased to announce the release of a CollabNet TeamForge plugin for AnthillPro. The TeamForge integration allows AnthillPro to work with TeamForge like it does other bug and story trackers. AnthillPro can:

• Create a list of TeamForge artifacts related to source changes
• Comment on those artifacts providing a link from a artifact (defect, task, story) to a build
  
• File new artifacts

TeamForge is more than a simple issue tracker though and provides neat features around release management. AnthillPro hooks into those release management features as well:

• AnthillPro can create new TeamForge Releases
• AnthillPro can upload codestation files (AP artifacts) to the TeamForge File Release System or upload a file to the FRS that links back to Anthill.
  

This integration was built against CollabNet 5.3 and is compatible with AnthillPro 3.7.3 as well as the 3.8 preview. Like AnthillPro, it is available for download on Supportal.