Category Archives: Uncategorized

The DevOps Toolchain Explained

Posted on by
Reply

Urbancode’s DevOps toolchain begins with a developer committing code to a source repository. Commit comments can be added so that uBuild will associate the code change to a bug report (Bugzilla, JIRA, Rally, TFS, TeamForge) or a feature story (Rally, PivotalTracker, VersionOne, Rational Team Concert).

uBuild will wake up periodically and build the code projects that have been changed during the latest period. The code changes, the execution of the build, and the output of the build are associated with this unique build. The build is then tested (JUnit, Selenium, HP QualityCenter, Cobertura) and analyzed (PMD, FindBugs, Coverity, CodeSonar, Rational AppScan, FxCop, Clockwork), and the outputs associated with the unique build. If the build, tests, or analysis determine a problem, the development team that owns the project is notified so corrective action can be taken. The entire process is known as Continuous Integration.  All projects in the enterprise that depend on this build can be set to build when changes to dependencies occur, and if a problem is found alerts that team. This is Enterprise Continuous Integration.

If the build passes the tests, the build artifacts can be automatically sent to uDeploy which will version them and automatically deploy them to a development environment for more automatic and manual testing, demonstrations, etc.  Once the development team is satisfied with their application, they can request a deployment to a test environment so the QA team can test. This deployment can have an approval process so it won’t deploy to test until the QA manager is ready for a new version and approves the deployment.

Development and QA teams can deploy the application to lower environments and DevOps teams can promote the application to higher environments. They use the same processes to orchestrate the deployment of software, data, and configuration to application servers (WebSphere, WebLogic, Tomcat, IIS), databases (Oracle, SQLServer, MySQL, DB2), infrastructure (F5), ESBs (Informatica, SharePoint, BizTalk, MQ systems), systems (Linux and Windows utilities). The deployment process can also coordinate with ticketing systems (Remedy, ServiceNow, HP Service Manager) and monitoring tools (Nagios).

For the deployment into production, the Release Manager can reuse an old release plan or create a new one using uRelease.  uRelease allows the release team members to know what to do and who is responsible for doing it.  As the release clock ticks on, the release team updates their activities like creating an outage request, using uDeploy to deploy applications to production, manually testing the deployed application, using uDeploy to rollback to the old version if needed, and sending out end of outage notifications.

The DevOps toolchain manages your applications from code all the way to the hands of your customers.  You develop, we deliver.

The Many Layers of DevOps

Posted on by
3

For many people, DevOps and infrastructure as code are synonymous.  However, I am usually quick to point out the other moving parts that need to be managed.  There is more to DevOps than infrastructure as code.  Once the infrastructure is in place we need to do something with it.  Application deployments, database updates, static content deployments, application configuration, middleware configuration, all of these things come into play after the infrastructure is in place.

There are many excellent applications for managing your infrastructure; tools such as Chef and Puppet obviously come to mind (they are easily the most popular).  These types of tools are perfect for making changes across multiple servers, and making sure your infrastructure is in sync.  They are also great for taking newly spun up virtual machines and making them identical the other servers in your environment.

Infrastructure is only part of the entire stack, and honestly it is not the most volatile part. New machines requiring infrastructure may be added daily but once the infrastructure is in place it tends to change less often than other components of the stack.  For example, the middleware configuration, the applications, and the application configuration all change much more frequently than the infrastructure.  Managing these changes is a crucial aspect of DevOps.

In the image above, the lowest layers can be handled by a number of tools.  These layers are typically handled by the major IaaS providers (Amazon EC2, Rackspace, and others), which involve provisioning of the servers, as well as the OS and the OS configuration.  Another great solution is to use Terraform or uProvision to handle the provisioning.  These tools enable companies to build an internal PaaS offering to allow teams to automatically spin up servers and make them available for deployment.

The middleware layers have a handful of solutions for automation.  Some companies include this configuration in the base image of their virtual machines.  Another popular option is using any of the “infrastructure as code” tools mentioned above.  These types of configurations can even be managed as part of your application deployment in an application deployment automation (ADA) tool such as uDeploy.

The application, and the application configuration can change multiple times a day in any continuous delivery environment.  Often it may only be the configuration itself (and not the binaries) that need to be deployed. uDeploy is designed to not only automate the deployment of the application but also provide visibility into which versions of changes have been applied and where.

 

Full application stack delivery with uDeploy, Puppet and Terraform

Posted on by
Reply

More and more people are telling us that they are using Puppet to provision and manage system tools and middleware. So we decided to see what uDeploy could do with Puppet. This led to the creation of a Puppet External Node Classifier for uDeploy that allows Puppet to manage middleware defined by uDeploy. We added our environment provisioner, Terraform(tm), to create virtual machines that have both Puppet and uDeploy agents on them. From there, Puppet calls uDeploy to determine the middleware it should install on the machines. Finally, uDeploy deploys the application to run on the middleware. Thus, providing delivery of the entire application stack with Terraform, Puppet, and uDeploy.

See how a Puppet-enabled enterprise can get supercharged by adding uDeploy and Terraform.–UrbanCode and PuppetWe will be demonstrating these products together at PuppetConf in San Francisco this week. So if you are in town, please stop by to say hello and see the demo!

We expect this first Puppet integration to provide the foundation for deeper integrations in the future, and we look forward hearing your thoughts.

uDeploy IIS Deployments with Auto-discovery

Posted on by
Reply

uDeploy has done a great job with IIS deployments for long time. We’re starting to add auto-discovery capabilities to our agents. When the agent starts up on a Windows box it will check for IIS instances and update resources with some common settings.

My colleague Steve Boone put together a three minute overview video of our IIS integration.

We’re still plugging away at putting the finishing touches on the auto-discovery capabilities. What sorts of things would help you when deploying to an IIS instance or site?

Other uDeploy and AnthillPro feature videos are up on the Urbancode Youtube channel.

Projects as Part of Interviews: We do that!

Posted on by
Reply

Michael Schrage wrote a piece titled “Projects Are the New Job Interviews” on his Harvard Business Review Blog. He observes that traditional resumes, interviews, etc. are failing. Some companies have responded by assigning project work to candidates to test real world skills.

As we look for more people, we at Urbancode do exactly this. Want to be our next UI / UX ninja? We’ll give you a screen or two from an existing product that we’re unhappy with. Once we tell you what our customers struggle with, we’ll ask for a mocked-up redesign and detailed explanation. When we meet again in a week, we get to see what you’re capable of in our world.

Michael points out that some companies use this approach to get free/cheap labor. The litany of angry comments in response to his article reinforce the real ethical concerns. We agree. Using project work under the guise of an interview to get below-market consulting is lame.

We pay our prospective future colleagues for their work – more than we’d expect to pay them as full time employees. While we’re looking for people who would see the task as a fun challenge, we don’t want their first experience with us to leave them wondering if we’re trying to screw them. Hiring is hard, time consuming and expensive. It’s a no-brainer to fairly pay people who get past the first interview rounds and for some project work.

Speaking of hiring. We’re hiring in our Cleveland headquarters.

Hit our jobs page if you:

  • Love your craft
  • Get stuff done
  • Take responsibility and ownership

 

uDeploy Quick Tip: Have a process wait a few seconds/minutes

Posted on by
Reply

Unfortunately, a lot of deployment documents that I see include steps like, “Wait two minutes” or “Give the process 30 seconds to start up”. While I usually look for a good way to monitor whatever is starting, having a step that just does a pause can be handy.

This is easy enough on *nix systems. On windows, or cross-platform deployments its a little trickier. Consider using the Groovy plugin for this. Groovy’s sleep command lets you insert the number of milliseconds to wait. So your script for a 30 second wait might be:

out << "Pausing for 30 seconds"
this.sleep(30*1000)