I recently had a professional challenge arise: I needed to become quickly conversant in a programming language I've never used before. It's been a while since I tried to cold-start with something like this... and I had a little fear of the unknown at the outset.
Through the experience of starting the app from scratch in unfamiliar territory, I realized that DevOps principles gave me a great foundation for how to start building something.
How we often start a project
mkdir project1- Open a file
- Write some code
- Does it run?
- Write some more!
- Goto 3
Heck, I know I did this a LOT along the way. It's common, because it's how we were taught. When I was in school, my instructors didn't educate anyone on Source Control systems or Project structures or any of the things that make for good, shareable, hygienic code. It was just "finish the assignment by Thursday and turn in your file". And if you needed a second file to separate concerns? Roll that sucker right next door, in the same directory. School projects never got bigger than just a few files anyway, so there was never any concern about what happened if your directory got messy.
How DevOps changed my project start routine
When I started working on build pipelines at work, we hit the wall on a couple projects that had been built in that haphazard sort of way. They expected a library file to be in a shared directory on a file server, or the whole thing would fail to compile. Naturally, our new CI/CD server didn't have access to this random file server (which wasn't supposed to be housing code!) and nothing would build.
I learned rapidly about the tremendous value of some basic standards, like:
- Source control
- Library package management
- Folder structures
- Automated tests and non-code asset storage
In addition, it forced me to answer a couple key questions much earlier than I'd ever done before:
- How do I move this code from one box to another?
- If someone new wants to contribute to this app, what knowledge do I need to share so that I don't spend all day showing them things?
In short, I came to appreciate well-organized code by having to automate the build and deployment of poorly-organized code! Now... back to the original storyline: I'm learning a language that I've never used before, and I need to start up a project.
I was a bit shocked that I caught myself building out my project just like I was going to put it in a CI/CD system! I had no build server to run it against (it's something that I run locally on my laptop to show in demo situations). It's highly unlikely to ever be built from a server and deployed somewhere by a pipeline. But those habits gave me a foundation... learning to set up package management so that I could use 3rd-party libraries easily, and make the app remain portable so that I could change to a different box and still download my app from GitHub and be up & running in minutes... those practices gave me something familiar as I navigated learning something new.
If you're new to DevOps, or even to coding in general, you should consider gathering some of these practices - even if you feel they might be a small amount of overkill - and implementing them every time you start a new project. Here's the list I've combined so far:
A Handy Checklist for Starting a New Project
Create the source control repository first. It's easy to set this aside for later, "let me get a working app and then I'll push it to GitHub". But really, it's not all that big of a deal to knock this out up front! This will subconsciously influence the way you start projects, preparing for the idea that they don't just have to run on your box. That mindset shift sets you up for lots of success later!
Before building anything, organize the directory structure along the language's standards. Some languages are much more rigid about this than others, but get in the habit of organizing your code from the beginning rather than having to refactor it into a coherent structure later. Most languages have settled on at least an "unofficial" layout. Follow it!
Set up dependency management. Creating a Software Bill of Materials for auditors may not be a requirement of your small personal project, but you benefit from doing this because well-managed dependencies are easier to work with!
Figure out what unit testing framework you're going to use and implement it before you write any actual code. If you're a TDD fanatic you can certainly write your test suite and then write your app to be able to pass it, but even if you're not, make sure that testing is a first-class citizen in your code. Having that
/testsfolder might not seem important but I bet you if you consider testing up front, you'll find a good use for it in your app and you might save yourself some headaches later on!
Some tips for achieving the checklist items
- Talk to an AI about what you want. ChatGPT, or Copilot, or any of the LLM products available will be able to help you get started with the basics. A great prompt to kick off this discussion is something like this:
"I'm building an application in $LANGUAGE, what's the generally-accepted way to manage packages? Please provide an example of what the standard folder structure would look like and how the package management would be implemented. Also recommend a good unit testing framework for this language."
Teach yourself to push code regularly up to GitHub (or whatever product you prefer)... and regularly pull it onto another box to ensure that it's easy to get it working. Getting in the habit of frequent, small pushes will help you when we talk about Agile and Continuous Delivery later in this series 😉
Add docs to your code repository from day 1 to document how to build and run the app, and update them regularly. If you try to write this later, you're going to miss steps that beginners don't know about and your documentation will be harder to follow. A little hygiene up front saves you a lot of work trying to onboard someone later!
Wrapping up
Someone who's new to coding often overlooks the preparatory tasks for getting started on a project, and makes things harder for themselves later. This can lead you to burnout and cause you to abandon your project before you complete it.
With a little preparation, however, we'll be able to minimize the obstacles and ship cool stuff more often!
Tune in next week, when we're going to dive into our first DevOps principle: Agility.
Top comments (0)