Just like "agile," the devops concept is really what the team decides. To borrow a phrase from the scriptures, devops was made for man, not man for devops...
In most cases, developers still deliver to a devops team - the "dev" in devops means the operations team becomes highly automated. Builds are all deployed based on scripts (Puppet, etc.). Separation of duties is somewhat maintained, but there are new challenges - like instead of picking up a package, devops tools access source code.
In some cases, devops means developers are truly the folks provisioning and deploying servers. This is a "nice" world to be in if you are a developer and you're sick and tired of having to jump through "all those hoops" set up by the operations team. The best way to resolve conflict and "impediments" is to simply eliminate the people who are behind them, right? This is a case where the Agile/devops approach runs smack into security best practices, because there are no limitations on access--devs literally rule the world and have root. Everywhere. Your business may not be able to tolerate this level of risk, in which case you will have to make an argument (a very convincing argument).
This is an excellent case study in how developers sometimes want what's antithetical to good security. My recommendation will sound strange - first, grab a copy of "The Phoenix Project" so you get a really solid understanding of devops and why some teams are attracted to it. Then sit down with the dev team and say "I understand why you want devops" (or "What are you looking to gain from moving toward devops?"). Then say "OK, but that decision introduces this risk. Help me work on a way we can reduce said risk." Ideas might include: use of Puppet and other automation scripts to eliminate manual interaction with servers (dev no longer need root), extraction of service credentials from source code and config files (leveraging Puppet scripts and limited access service accounts to pull passwords from servers), implementation of change detection and change control technologies, creation of a dedicated devops team, eliminating developer access to production entirely... The path to devops can ultimately lead to higher security, if you're willing to let it and you can get buy-in.
In some organizations, dev rules the roost - they build the code that makes the money, so teams are very reticent to do anything to slow that down. However, a well-designed devops implementation can accomplish both goals - smooth, frequent delivery as well as separation of duties and other security concepts