Congratulations, you just scored your first job. Fresh out of college. It pays decently and the interviewers seemed nice. There are all sorts of perks. It even sounded like you would work with some bleeding edge technologies.
So now you're ready for whatever tasks they'll throw at you. You started yesterday together with a few college grads. You spent the day yesterday getting access to the building. You know now how to both obtain lunch and relieve any pressures such a feast might impose on you.
You've got your state-of-the-art laptop booted and are ready to make the world a better place, To innovate! To use all the skills you've gathered while studying at the university.
Your project manager calls you for a meeting and let's you in on the details on the first task that you'll complete.
He truly knows that you are very eager to get started and do cool stuff. But unfortunately they have a Go Web application that runs in production at a bunch of customers, and no one quite remembers how it works.
It's called Simple Fortune Cookie, everyone asks their visitors about cookies these days. You get it, right, don't you? Ahh never mind then....
The application is Simple Fortune Cookie, fortune cookie as a service. It isn't perfect, but nevertheless, it brings in some cash.
It is obviously important to keep this application running well and good, otherwise we might end up looking very bad indeed.
"Oh and.. have you heard of DevOps and Cloud Native? Do some of that, we've heard it makes things better."
Congratulations, on your second day you became the proud owner of a piece of Legacy Code.
Now, where to start?
You've been handed a huge pile of .. Well you do not quite know of what.
You know that you need two things in order for you to be a success.
You need to know what is happening to the code and who is working on what.
The first steps are obvious.
Put your code under version controleasy!- Set up issues to track your progress.
Soon™ you'll be presented a lot of individual tasks to complete. Just as with any other project, you will want some way of managing which tasks you are currently working on and what is on you backlog. So create Issues in your GitHub repository to track your progress.
It is good practice to always mention which issue you are working on in your commit messages. GitHub will actually use this information to link your issues and commits together in the UI, giving you valuable traceability information.
The even cooler next step is to use GitHubs build in automation to automatically close issues when you commit the change. See Closing issues using keywords.
Optional task: you can also set up a project inside github to do full fledged project management. Link: Automation for project boards.
... and now on to the actual project work.
In the following documents you'll find the different tasks, they're of course unordered ideas from management, but you'll probably find that it makes sense to do some before others.
"First of all, the datacenter we used crashed last night, so we'll need you to deploy the application again, but that shouldn't be a problem, you've found the code, right?"
💡 the numbers indicate a way to make a natural progression, saying "take all 03's before 04's". It is not mandatory to do it like that however so feel free to change if needed.
- 02-run-app.
- 03-containers.
- 03-automation.
- 03-container-registry.
- 03-container-orchestration.
- 04-cd.
- 04-database.
- 04-testing.
Of course, things take time, but if you could try to focus on everything, and then afterwards start on this, that would be so great.