Answers: <p>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.</p>
  
Answers: CC BY-SA 4.0
Answers: 2022-01-26T09:25:39.500Z
Answers: 2022-01-26T09:25:39.500Z
Answers: petrchpetr
Answers: <blockquote>
  <p>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 &quot;user
  story&quot; or request changes. There is just a lot of things I've known
  for a long time that need to be done.</p>
  </blockquote>
  <p>Do the users have a <em>platform</em> 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 <strong>documentation</strong> too.</p>
  <p>I would also work on the <strong>automation</strong> of build &amp; 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.</p>
  <p>DevOps is not just a process, it is a state of mind too.</p>
  <p>One more suggestion: since you depicted your own software as buggy I would focus on improving <strong>code quality</strong> and reliability. Especially if this is a source of dissatisfaction or frustration - then it should be a priority.</p>
  <p>For this add <strong>monitoring tools</strong> if you don't have any: collect application <strong>logs</strong>, 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 <strong>proactive</strong>, and communicate your improvement strategy toward your users.</p>
  
Answers: CC BY-SA 4.0
Answers: 2022-01-28T18:17:06.383Z
Answers: 2022-01-28T18:29:47.343Z
Answers: 2022-01-28T18:29:47.343Z
Answers: Kate
Answers: <p>Devops will help you find bad code path or dependencies, which cause issues down the line.</p>
  <p>As you are responsible for both sides of the coin(developer/OPs), you can Integrate lessons learnd as ops into your work as dev.</p>
  
Answers: CC BY-SA 4.0
Answers: 2022-01-27T13:06:01.613Z
Answers: 2022-01-27T13:06:01.613Z
Answers: Max N
Body: <p><strong>Background:</strong>
  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).</p>
  <p>The software, which began as a hobby project as I was learning Java, has become &quot;mission critical&quot; to our company and I am still the sole developer building and maintaining it.</p>
  <p>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.</p>
  <p>As a result of this ad hoc approach, the software (with over 60,000 lines of code) is poorly documented, buggy, and full of &quot;amateur&quot; code I used to &quot;just make it work&quot; as I was learning. I also still manually build and deploy each release (I do not use any build tools such as Maven). <em>I do use Git/GitHub for version control.</em></p>
  <p><strong>DevOps:</strong> I have recently become a certified <em>SAFe 5 DevOps Practitioner</em> 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.</p>
  <p><strong>Question:</strong> 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.</p>
  <p>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 &quot;user story&quot; or request changes. There is just a lot of things I've known for a long time that need to be done.</p>
  <p>Any insight would be greatly appreciated, but is DevOps even suited to a single developer environment?</p>
  
Tags: <cicd>
Title: How to apply DevOps with just one developer?
UserDisplayName: Zephyr
ThreadText: # How to apply DevOps with just one developer?
  
  (Asked by: username_0 on 2022-01-22)
  
  **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?
  
  **Tags:** cicd
  
  
  ---
  
  ## 3 answers
  
  ### Answer by username_1 on 2022-01-26. Score: 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.
  
  
  ---
  
  ### Answer by username_2 on 2022-01-28. Score: 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.
  
  
  ---
  
  ### Answer by username_3 on 2022-01-27. Score: 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.
  
  
  ---
  
  