Results 1 to 5 of 5

Thread: Distributing tools to outside companies

  1. #1
    undefined
    Join Date
    Aug 2008
    Location
    Chicago
    Posts
    8

    Default Distributing tools to outside companies



    I'm just wondering what type of setups you guys use to distribute tools to outside companies or clients. Right now we are having issues with Windows 7 and permission distributing through an .mzp. And just general issues with making sure people are up to date, etc.

    Just curious to what else is out there, or what else is being done.

    Thanks

  2. #2
    program Theodox's Avatar
    Join Date
    Mar 2012
    Location
    Seattle
    Posts
    672

    Default Big kettle o' fish

    A lot depends on your security enviroment and needs -- and on your level of trust with the outsourcers. A high-trust relationship, say between two studios in the same company located in different cities, is easy; a low-trust situation (a new outsourcer, an individual freelancer, or a studio operating in hack-friendly countries) requires a lot of planning.

    Typically you want to ship two pieces: a simple shim that is installed directly and hardly ever changes, and then the main tools harness that you version check and download as needed. It's a nice courtesy to include an un-installer, or an off switch -- the outsourcers often work on multiple projects, it should be easy for them to be in 'you mode' or some other mode and know which mode they are in.

    The shim is the shortest, dumbest bit of code you can write that figures out if new tools are available and downloads them if they are out of date, then runs the main toolset's startup routine.

    The main harness is the actual toolset. It should be distributed as a unit (not loose files!) to make sure that all the pieces are at the same version -- for remote distribution, stuff like a locally locked file that won't go away or a file that perforce won't clobber are nightmares to find and fix. A single archive is much easier to validate. Any dependencies (like external dlls) should be included here as resources -- the harness should extract them and place them where they need to go on startup. Its a very good idea to have some kind of automatic testing that makes sure you can run with nothing except the shim and the distribution -- it's really easy to miss a dependency and very hard to debug remotely.


    Distributing the harness can be done online with HTTP or FTP, or using source control. In max you can do the downloads with dotnet, in python it's a batteries-included built in. Network solutions are nice because they don't require much user intervention and don't give users the option to opt out. One important side effect though: this ups the burden on you to make sure that all distributions are tested and work out of the box -- autoupdate + crash-on-startup = disaster). Nowadays it's easy to get a cloud server from something like Amazon to host the tools distribution, that keeps your internal dev environment isolated (no need to poke a hole in your firewall for tools request) and it also guarantees uptime -- probably better uptime than doing it in house. However you need to have IT and managment that are comfortable with tools sitting on the internet; personally it's fine with me, since I know how easy it is to open up mxs or python files on somebody's local machine for prying -- but many companies will flip out at the thought of proprietary tools out on the net.

    Plain old source control syncing works as well, but since it is opt in you'll have to expect some large % of users not to bother. Auto sync guards against that -- but it also means that perforce information (server address, user, and password) will be in the code and accessible to prying eyes. It also means you have to put source control code into your 'shim' -- which means it has to work with no perforce dlls yet, so expect ugly command line mongering if you go that route. Naturally, it won't work unless the users have correctly configured source control installed. And, of course, it only works on people with access to your depot. Many companies will never let that happen.

    As far as security goes: you should scrub the tools for any info you don't want out in the wild - if your tools include, say, an email error handler that sends on a company address you should assume that the account is publicly visible; neither maxscript nor python can really guarantee your secrets will be kept. You can minimize 'internet' worries by providing your outsourcers with a local server that does net distribution on a LAN -- then you're only responsible for remotely updating that one box and you can assume the tools are all at the same version at that location. It's almost as good as net distribution and it keeps your stuff off of the whole internet. It's still true, though, that you have to assume every line of tool code is publicly available to anybody who knows the basics of mxs or python. Sort of like online games, its safest to assume the client is in the hands of the enemy :)

    Lastly, there's always the email-a-file solution (again, this would be the 'lump' or distrbituion of the main toolset). Your outsourcers may not have internet connections at their desks (this is common in China). It's not very nice because (a) it depends on human beings and (b) those human beings are somewhere across the world and (c) you can't get them fired if they screw it up. If you do something like this, at the very least consider something like including an audit tool that lets you know what versions are being used on what machines -- then you can at least send emails saying 'half of the artists are using an exporter that's six months out of date'. This isn't much help if your outsourcers have no interned access, alas, but you can include some of this logging information in your deliverables to get at least some visibility into what they're using. Good metadata in the pipeline is also a must here.

    Last but not least: Make sure that branching tools for different shops isn't going to kill you. Ideally you would keep everybody on the same code line, but it's highly likely that something will go wrong ("there's no version of max 2012 in Hungarian!", "Our exporter won't work in non-english character sets", "they're already mapping something else to the X: drive") that requires a slightly different code path between outsourcers and the main studio. It's better to do it in a real branch rather than in dozens of IF/THEN statements littered around your code.

  3. #3
    kindergarden cop RobertKist's Avatar
    Join Date
    Nov 2008
    Location
    Shanghai, China
    Posts
    176

    Default

    If your outsourcer is in China (like us) then I'd recommed the following:
    - avoid always on connections to your server. Or at least assume they're not always on. Always check for disconnects and timeouts.

    - avoid sending large files if you can avoid it. i.e. don't send a whole 1gb installer package if you just update 2 or 3 files. do incremental updates, patches, etc instead.

    - some scripts (especially max scripts) may break with a Chinese (or non US) windows system local, especially if your mxs code has non standard characters (like the (C) character). The Chinese system will try to interpret this as chinese character and your script will crash. This can, in theory, apply to other software/scripts as well.

    - at my company most users have no internet, but our IT can forward P4 access or for heavy P4 use install a P4 proxy.

    - at my company registry write access is blocked, except for installers

    - juniors may have no write access to C:/program files - so IT has to be called to install anything in there.

    - make sure your programs can deal with unicode text inputs and file-names. At least they shouldn't crash right away.

    - make your tools easy to troubleshoot for the outsourcer's IT/TA. With a time difference of up to 12 hours (e.g. East Coast) we lose an entire day if we cannot fix a problem ourselves and we may bill you for it. Not good.

    - keep time difference in mind for your tool update schedule. E.g. if we come to work in the morning and have to wait 1 hour to download updated tools, we're losing time.

    - "your tools are not the Borg!", meaning that we have OTHER clients beside you, so your tools should play nice and not take over the entire system. And if they do, warn us ahead so we can prepare special workstations just for your project. Uninstallers are great too!

  4. #4
    Administrator Rob Galanakis's Avatar
    Join Date
    Jun 2008
    Location
    Reykjavik, Iceland
    Posts
    1,242

    Default

    Be a deployment boyscout: http://www.robg3d.com/?p=825
    Don't forget outsourcers: http://www.robg3d.com/?p=938
    Forum Administrator
    www.robg3d.com

  5. #5
    undefined
    Join Date
    Aug 2008
    Location
    Chicago
    Posts
    8

    Default

    Thanks for the detailed explanation guys. I'll pass this on to my team.

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •