What is DevOps-driven application development?

DevOps-driven application development is the process of using DevOps to build applications. In a traditional application development process, developers are responsible for developing and deploying the code while maintaining the production environment. DevOps driven application development changes it by bringing both developer and operations team together.

Why do you need a DevOps-driven application development process?

1. You can get code deployed faster, just like the developers. You will not need to wait for five days for a developer to deploy your changes anymore. Everyone in a team can make production-ready changes and push them into the live environment to fix bugs or add new features. Developers can interact with the production environment throughout the development cycle.
2. You can be assured that your code is stable and secure because you have an operations team to help create, test, and deploy the changes. Your organization may also benefit from software quality improvement by reducing defects through a more rigorous QA process. For example, if a developer tests his new feature by making a few changes and the resulting code is not stable or secure, the continuous integration testing will fail. In DevOps driven application development, the operations team can integrate new features into the test environment to ensure that the CI process passes before handing over the change to QA.
3. You get faster issue detection and fixing. As mentioned above, everyone in the team can deploy changes into the production environment. It means that if a developer finds an issue in the live system and needs to fix it immediately, he can push a new change into the live system without waiting for the operations team to get back from their break.
4. You will see more collaboration among your team members. DevOps may seem very technical at first, but it does not mean that everyone in the team needs to be a developer. The operations team and developers will learn more about each other’s work and get along better as they work side by side on the same project.
5. You will have lesser conflicts between QA, developers, and operations. In traditional application development, you can see a lot of finger-pointing as each party blames others for the system failure. If everyone works closely on one team and shares risks together, conflicts will be easier to resolve. A developer may see problems in the QA environment during his daily work. He or she can tell operations that it’s causing a lot of instability in production, and the QA team will not get the blame.
6. There will be lesser chances of system failure due to manual errors. How often do you see a developer rushing to fix an issue when they accidentally broke something? Bugs caused by manual mistakes are very hard to catch because developers need to debug their code. With DevOps, you can ensure that your system has 100% test coverage before deploying the changes to production.

How should a DevOps-driven application development process run?

It is good to start with CI (continuous integration) and end with staging and product release.
Below is how it runs:

1. Developers identify an issue in the source control system.
2. Developers will create a pull request in the source control system, which is automatically detected by the CI server. The CI server will run all the tests and report the result to both developer and operations team. If tests fail, you can fix them immediately and push a new change into the production environment through the web portal (like GitLab).
3. Operations will be notified of the new change and can deploy it into the staging environment to test it before product release. If everything goes well, operations create a pull request in Gitlab, similar to developers creating pull requests on the source control system. This may sound redundant, but you want to keep all your changes in one place so that you do not have to go from system to system and find out what you broke or need to troubleshoot why things are not working.
4. After product release, customers will be notified of maintenance outages in the Google calendar that are shared with all team members. Each team member can set up their task using a project management tool (like Jira) or reply to the google calendar event that indicates what they are working on during maintenance.
5. If a developer found issues in a production environment, he/she can fix it now and push a new change by creating a pull request in the source control system. The operations team will be notified of new changes and should test them thoroughly before pushing them into production.
6. If a bug is found in production, the developer can fix it without upsetting customers by pushing new changes into the staging environment directly from the source control system.
7. You should work closely with your customer to ensure that he/she understands how you will deploy and test changes and give them access to Gitlab so that they can see what is going on. He/she can see all the changes in production and staging environments, discussions about bugs reported by customers, and others.

For more details on how PureSoftware can help with DevOps-driven application development, please write to us at info@puresoftware.com.