The DevOper in Beautiful Delivery

The DevOper in Beautiful Delivery

If a developer usually wants to push for change and the operator works against it, what happens if you combine the two roles? In this blogpost Christian Forsberg gives us some clarity in what it means do be a DevOper.

The main responsibility of the DevOper is to create a solid implementation of the end result and make sure that it runs smooth in operation. The role name comes form the term DevOps, and indicates that this is a developer that make the implementation, but also takes care of the operations of what he implements.

This used to be two separate roles with very drastic differences in approach. The developer usually wants to push for change and implement new and cool features, while the operator works against change to keep things as stable as possible. Both are right, of course, and I thing the best compromise is usually achieved when both roles are combined into one person – a DevOper. It’s amazing seeing this in action, when the developer part of this person gets a great idea of some new implementation and says “let’s do this now”, and then the operator part of the same person realizes the consequences of the new implementation running in production and says “well, let’s make sure this is stable, so let’s wait a bit”.

So the main task for the DevOper is to create the actual implementation, which means to create code that correspond to both the functional (user stories) and non-functional (availability, response time, security, etc) requirements. Besides coding the user interface and logic, it most often also includes the data management of SQL or NoSQL databases. Common tools are integrated development environments (IDEs) like Visual Studio and IntelliJ, as well as tools for database management.

What is a Beautiful Delivery?

Another important task for the DevOper is to create and manage the continuous delivery pipeline, and the ultimate goal is to automate everything. I like to set a goal of one single click to set up the development environment, and then everything should be automated from there. When the DevOper commit code to the source code repository, it triggers an automatic build (compile), which in turn trigger the run of automated (regression) tests, and if those are successful, an automatic deployment (if it’s server components) or an automated distribution (if it’s a client component, like a mobile app or firmware in a connected thing) is made. Common tools are Visual Studio Team Services (VSTS), Jenkins, and HockeyApp.

As the DevOper is also responsible for the run in all environments, including production, it’s important to be familiar with cloud computing. Most organizations are moving to a multi-cloud approach, and therefore it’s vital with knowledge about clouds like Microsoft Azure, IBM Cloud, Amazon Web Services, and the Google Cloud Platform.

It’s a common prejudice that programming can easily be automated, but coding is creative work, and I consider it fine art, just like composing music, painting, and sculpture. Even if computers already try to simulate such work, it will take ages before they will surpass humans.

Feel free to discuss the content of this blogpost with me!

todo todo
  • Christian Forsberg
    Christian Forsberg
    CTO Sogeti Sweden/Global Chief Architect
    070-593 03 18

    Sorry, this content can only be visible if Functional Cookies are accepted. Please go to the Cookie Settings and change your preferences.