1

Background: I am a self-taught Java developer, focusing mostly on desktop JavaFX applications. I work for a large company and have developed a fairly large piece of software that is relied upon by my department of over 100 employees on a daily basis (it is our primary knowledge management suite of applications).

The software, which began as a hobby project as I was learning Java, has become "mission critical" to our company and I am still the sole developer building and maintaining it.

The entire development cycle for me would be coming up with ideas myself (I used to have another position in the company so the workflow was familiar to me), asking coworkers for input, and then deploying updates as I wished.

As a result of this ad hoc approach, the software (with over 60,000 lines of code) is poorly documented, buggy, and full of "amateur" code I used to "just make it work" as I was learning. I also still manually build and deploy each release (I do not use any build tools such as Maven). I do use Git/GitHub for version control.

DevOps: I have recently become a certified SAFe 5 DevOps Practitioner but I have not had the chance to put much of it into practice. I understand the core principles of Agile and have a very limited amount of experience working with it.

Question: As a developer who has always worked alone, how can I apply the DevOps methodology to my workflow? Without a team of developers to work with, every piece of the development lifecycle rests on me.

I have tried following the Agile principles of meeting with the software's users to better understand the business value and such, but there is a lot of old code that also needs to be corrected or improved, though the users do not usually contact me to submit a "user story" or request changes. There is just a lot of things I've known for a long time that need to be done.

Any insight would be greatly appreciated, but is DevOps even suited to a single developer environment?

3 Answers 3

2

I went through a similar path. Every time you touch your code do something in that direction. You zip your app manually? Do it via a shell script. Every time you see something you know you can express as code, do it. The technology does not matter. Over the time these steps will join together. For example - if you know how to unzip and set up your application on a production server, you can wrap it in something like AWS Code Deploy and next time you trigger the process from a command line. Then you add a git repo hook, etc... You will learn more along the way and you fill find solutions which you cannot see now. Every login you don't have to do, every mouse click which you do not do is a change for better. It will free your capacity for some other problem. It is also easier to redefine the pipeline with some higher level tools once you have code blocks which clearly state what steps are needed.

0

Devops will help you find bad code path or dependencies, which cause issues down the line.

As you are responsible for both sides of the coin(developer/OPs), you can Integrate lessons learnd as ops into your work as dev.

0

I have tried following the Agile principles of meeting with the software's users to better understand the business value and such, but there is a lot of old code that also needs to be corrected or improved, though the users do not usually contact me to submit a "user story" or request changes. There is just a lot of things I've known for a long time that need to be done.

Do the users have a platform for reporting bugs or requesting changes ? I mean, something more formal than E-mail ? If not, it's something I would work on, and you can use the platform for documentation too.

I would also work on the automation of build & deployment since you've clearly identified this as a possible improvement. Try to automate as much as you can, especially the boring and time-consuming stuff.

DevOps is not just a process, it is a state of mind too.

One more suggestion: since you depicted your own software as buggy I would focus on improving code quality and reliability. Especially if this is a source of dissatisfaction or frustration - then it should be a priority.

For this add monitoring tools if you don't have any: collect application logs, investigate errors, fix them and update your code before the users come to you to report issues (if they even bother doing that). The idea is also to become more proactive, and communicate your improvement strategy toward your users.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.