How do you manage SQL jobs that belong to a database? We just had an issue where we lost msdb on one of our servers along with all of the jobs which we created for a multitude of databases. The fact that we didn't have a backup of msdb is one issue, which I won't get into, but it did make me think about how we develop the jobs that go along with our databases.

What are the different ways that one could manage jobs? I guess ideally they would be in source control, but I've yet to find any tools which do a good job of managing large systems of databases with their associated jobs.
So let us begin with the obvious: Back up your msdb database. Get a maintenance plan going, back it up regularly, and let us never lose our jobs or job history again.

This also leads to the second part of my answer which is: jobs and their steps are just rows in a table. They have steps which invoke subsystem commands using arguments provided in the job step row. The only way ultimately to "manage" the jobs is by managing the SQL that creates / modifies / deletes them. And because there's surprisingly little customization for a given job step, most people have just stuck to static SQL scripts for deployment. 

Build your job in dev, test it, script it out to SQL, store it as a post-deployment file in your database project (your databases are in source control ... right?) and you've got the path of least resistance to SQL Agent job management.

Maybe someday in the future there will be ways to "compare" jobs in a project to a target server job a la Schema Compare - again, it's just SQL, shouldn't be too hard to reconcile - and then publish changes (even bidirectionally!) but for now you're just stuck with scripting.