Autopkg is a project born out of the need to automate one of the more tedious tasks that face Mac Admins: figuring out when a piece of software has been updated, downloading it, and doing whatever it takes to make that software 'live' in your distribution or management system of choice. Munki was designed more recently than some other software distribution systems, and started out with the concept of 'tracks' or phases a piece of software will go through before it is offered to all of the clients participating in the system. Autopkg can integrate with it by simply copying the downloaded package into the repo, among other actions that have the potential of offering the software to clients immediately.
The JAMF Casper suite has many similar features, but as it was built under different circumstances it has other considerations and steps one would use when approaching the same set of tasks. Autopkg does not consider one software distribution system more special than another, and presents an open framework for folks to integrate with as they see fit. I have taken it upon myself to publish a 'processor' python file which, along with standard prefs for leveraging the JSS API, can not only 'upload' the fetched package to the JSS's distribution point, but can also configure a smart group(since version 9 of the JSS) and/or a self-service policy which therefore makes the software immediately ready for testing. Optionally, one could target any pre-existing static group(which also should work on version 8.)
To get started testing and evaluating it, please recognize that there were specific design decisions taken into account for this integration. We're mimicking Munki's pipeline-to-testing, where admins need to do as little as possible to have the software automatically imported and made 'live' in the system. Here's a high-level workflow: Preferences are set to point to the locally-mounted jss distribution point, the url of the jss, a user with api write access, and that users password.
defaults write com.github.autopkg JSS_REPO /Volumes/JSS_Dist_Point/Packages
defaults write com.github.autopkg JSS_URL https://test.jss.private:8443
defaults write com.github.autopkg API_USERNAME apiUser
defaults write com.github.autopkg API_PASSWORD apiPassword
The autopkg tool is then run, pointed at a product's jss-specific recipe(e.g. autopkg run AdobeFlashPlayer.jss.) Categories are created by product name to arrange the imported software(which you can turn off or customize if you'd wish. The software is prepared (with optimizations so it works in more scenarios in some cases) and copied to the distribution point mounted at a local path.
Then, in an effort to 'do no harm', we create a smart group that is scoped to all of the computers in inventory that are not at this version of the software(in case users have already installed it.) It also creates a self-service policy with that group added to it by default(although it can optionally be statically scoped to any group name.) Therefore it doesn't get pushed, just imported and is ready for testing unless you have other plans of how tom more optimally put it in production for your organization.
For an installation guide, take a look at the autopkg wiki and other resources including the MacTech articles and MacSysadmin presentation Greg Neagle gave this past year. Having the jss-specific tools installed doesn't do anything without the actual recipes to build the packages, so I've created two dozen to start with. I have pushed those to github as well, which makes them trivial to fetch using the autokpg tool itself.
autopkg repo-add https://github.com/arubdesu/jssRecipes
Many of these rely on the main autopkg recipes repo as a 'parent', so minus the munki-specific instructions, make sure to add those to your local system as well. I'm definitely in need of testers and feedback when it comes to the ways folks want the workflow sculpted to their software deployment methods, so please do let me know what you think!