The Social Framework is the most important part of your automated testing initiative. If you want your developers to build and maintain tests, you will need a social structure that encourages them to do it.
Your social framework will be a lot stronger if the people who approve and start releases are also the people who make the automated tests. Nobody wants the pain of approving a release, and then rushing back from Friday night beers when it breaks something.
In most continuous release shops the developers approve releases, and the QA team is available to help them on a consulting basis. In these organizations, developers make useful test scripts.
In my experience, code review is the most effective way to get tests. You tell the team that code changes must be reviewed before they are accepted into the shared build. Then, you check the contributions, and if they need related tests, you ask for the tests.
Some of the people on your team will be enthusiastic about testing, and they become your enforcers. You can do it in pairs, where each person reviews code from his or her assigned buddy. This is like pair programming, but a lot more efficient. Other approaches include asking tech leads to review code from their contributing team members and setting up group code reviews with voting.
Assembla offers features to help you with any of these review mechanisms.
In test driven development, before writing code developers write tests for it, as a sort of specification. This process gives you a lot of automated tests. You will find that some people in your organization have patience for this process. They will argue that the slow pace of this process is more than offset by the increase in quality that comes from thinking through logical requirements and writing them down as tests. Others in your organization will strongly disagree. I recommend going back to code review as a way to resolve this issue.
You can send the responsibility for making automated tests to a QA professional or team. This is a good way to free up your developers, if you have a regression testing framework that is designed for QA people.
However, outsourcing to QA can introduce some inefficiency. Because the QA guys are paid to make tests, they are often slow to notice when the tests aren't finding problems, or require a lot of rework.
Some developers will apply pressure for maximum code coverage. Code coverage is the percentage of lines of code that run when you run automated tests. I am not sure if it is an important measure. If a change breaks something, it usually breaks multiple tests. You can have limited code coverage and still find enough problems to shorten your testing period and give developers confidence to make changes. To get started, you can write tests only for bugs that get reported. Since bugs cluster together in evolving or difficult code, this strategy will find many errors with a limited number of tests.