I talk with customers every week, and there are a number of common topics that come up. The howto video subjects can come from those conversations, or from specific requests. This week, I had a couple of different users ask how to get started with software packaging, and it occurred to me that it'd be useful to talk about the basics: where to start. This video (script attached below) is the first video along those lines. I cover a bit about common practices I use, and a couple of bits about where basic software packaging is regularly used (hint: full stack provisioning, and Cloud.)
Take a look at the video (attached and also on youtube), and let me know your thoughts and questions.
Hi, my name is Sean Berry, and I work on the Customer Engineering Operations team, specializing in Data Center Automation and Cloud Lifecycle Management.
So, you've got a working BSA instance, agents deployed, etc. and now it's time to deploy some software. Software packaging and deployment is a common task within automation, and a good opportunity for potentially serious time savings, especially on more complex packages. It can also rapidly increase the rate at which new servers can be built. Most organizations have automated the building of a basic server, but the follow-on deployment of the different monitoring, backup, and security agents, server hardening, patching, and compliance validation steps can still take days or longer. In other organizations, it can be the work of weeks or longer to roll out or upgrade a particularly thorny software package. The obvious place to start is with basic software deployments.
For today's purposes, we're going to work with a simple example package, a compression utility called 7zip. Any MSI that has a working silent install will work here, and most MSIs fit this requirement.
First we'll need a server to deploy this to: you've probably got many servers available, but in this "lab" environment, I need to add a machine. I've already defined its hostname and IP address in the system "hosts" file, while you're probably using DNS in one form or another. I'm now going to add "win08-www" as a server, I'll click on ok, and it'll appear in the server smartgroup when I refresh it. I like to double click on a server when I first add it, and browse a couple of object types to make sure everything is happy. Here's the applications list.
Ok, now we need software. I've taken the liberty of downloading this one, and stashing the executable in the c:\temp folder. Now all I need to do is browse to the depot, go into the workspace folder, right-click, and select new software object -> MSI, and browse to the c:\temp folder on the local machine (as opposed to on another server or a central file server: that'll come later). Once I select the object, I have the opportunity to customize the installation instructions, add any additional options I might need. Since this is a very simple software install, I'm going to leave all of this alone and hit OK.
Ok, now that I have my object, I need to deploy it: refresh on the depot folder if necessary, right-click, and select "deploy". This creates a Deploy Job. Between how the object itself is defined, and any customizations made to the job itself, they define together how to get software from the depot to a server. The Deploy Job is used as a part of a Post Provisioning Batch Job, and by CLM to build a server a certain way.
Every job needs a name, and a place to live: while developing new packages and jobs, I will commonly keep these in a Workspace folder. Once I'm comfortable that they are useful enough to share with others, I'll promote them into shared spaces, like a shared "Software Deployment" folder.
I usually skip the "Simulate" stage when I'm developing a new software package, it saves a bit of time, and I'm usually confident that the new server is up and has available space. I will usually select "Execute Job Now". I will also usually increase the logging level from "Errors and Warnings" to "All Information", but only for testing and while I'm making sure it will deploy cleanly. Once it's ready to go to production, I'll change the logging level back, since the "All Information" level generates a lot of information.
Once I click ok, the job will start executing. While keeping an eye on the "Tasks in Progress", I'll either login to the machine directly, or look at the "Applications" object, which has the same things as the "Add/Remove Programs" Control Panel. Once I see the application appear in either place, or a directory I expect it to create appear, I'll check back with the job results, make sure it deployed cleanly, test the app a bit, then hand it off and start working on the next app. Congratulations: you've packaged a simple app, and can now work on either upgrading an older agent in your environment, or combining it with other apps and configurations to build out a full provisioning stack.
Many apps require no more work than this to automate, but we'll look at a couple of more complex use cases another time. Thanks for your time, and thanks for using BMC software.