Producing working software involves much more than just writing code.
Most substantial software applications require some kind of data storage, and they have to be built, tested, and deployed somewhere.
And you know what?
We need people who know how to handle that kind of stuff and to do it.
That is where the roles of DBAs (database administrators) and DevOps come in.
You might be wondering why you need to know about all that—can’t you just write the code?
Well, yes, sometimes you can just write the code, but more and more teams are becoming cross-disciplinary, and software developers are being required to take on—or at least contribute and work with—a variety of different roles.
Software development, especially in Agile environments, is more of a team effort, and we’ve added a whole bunch of best processes and “ways things should be done” as we’ve learned over the years how to deliver better and better software. (Or at least we think we have.)
Anyway, as a software developer, you may be asked to wear several different hats, especially if you work for a startup or small company where there isn’t a dedicated DBA or operations team.
It’s not unlikely that someday you’ll be asked to install a database or set one up to work with an application.
Likewise, you may be asked to help determine the process of taking the working application code, getting it built and tested, and deploying it to a production server.
Or, you may also be asked to work with one of these strange creatures who call themselves DBAs or DevOps… dudes?
Anyway, regardless of the reason, you should probably learn something about your technological brethren.
Oh—and we’ll get to Quality Assurance later; that deserves a whole chapter by itself.
DBAs
First, let’s start with DBAs.
What exactly is a DBA, or database administrator?
Well, the role can vary from organization to organization, but generally it involves hurting developers’ feelings by telling them their code sucks and is utilizing too many database connections and telling them “no” a lot when they ask if they can do various things involving the database.
For the most part, though, the DBA is responsible for setting up, maintaining, securing, optimizing, and monitoring the databases, and perhaps even setting up database schemas or writing stored procedures.
Some DBAs tend to be very operational in nature and don’t do much in terms of actually creating database tables and writing any kind of database code.
Other DBAs are more like database programmers in addition to the operational work they do on the databases.
Databases Need Care and Feeding
Not every development team is going to have a DBA.
In fact, many organizations are going to have developers—that’s you—doing many of the DBA duties, so it is useful to know your way around a database and some of the basics of installing and maintaining one.
For many software applications, the database is an important piece of the business, so whether the role of maintenance and administration falls directly into the hands of a DBA or is distributed amongst developers, it’s quite important that someone does the work.
Databases grow over time and can be pretty big resource hogs, so it’s critical to pick the right hardware to run a database on and to determine when it’s time to upgrade.
Databases also contain some pretty important data, so care has to be taken to back them up regularly, and someone needs to put together a disaster plan to restore a database or keep things running if one happens to fail.
And let’s not forget performance. Over time, databases which are not well designed or tuned can get slow and inefficient, so special care has to be taken to profile the database and determine how the data should be arranged or indexed to make things faster.
I could go on and on, but I think you get the point. Databases don’t just raise themselves.
Do I Need to Be a DBA?
No, but I’d highly recommend you invest some time in learning how to:
- Install and set up a database.
- Create and restore backups.
- Create tables and schemas.
- Create stored procedures.
- Index tables and how indexes work.
- Perform basic operations like queries, inserts, updates, etc.
- Join tables.
Like I said, you don’t have to be an expert in all this stuff, but knowing the basics will be extremely helpful in your job as a software developer, whether you have to do some of this stuff yourself or you have to work with a DBA.
DevOps: A New Role
It’s not too often that completely new roles are invented in the IT field, so the role of DevOps is both unique and a little, shall we say, loosely defined.
What exactly is DevOps?
Well, it’s a conglomeration or a mashup, if you will, of development and operations.
In my mind, I think MacGyver.
If you ask different people, you’ll get many answers, but for the most part they’ll agree that DevOps is all about doing whatever needs to be done to get the code built, tested, deployed, and running in production.
But to really understand and appreciate DevOps, you have to understand…
Operations: How We Used to Do It
You see, before there was DevOps, there used to be just developers and operations (sometimes called IT).
Developers wrote the code, then they threw it over the wall to QA.
QA would say it sucked and throw it back.
The code would go back and forth a few times before one party or both finally gave up, and then they’d collectively throw the code over another wall to the operations team.
The operations team would complain about how inefficient the code was, how it was going to break the server, and how developers don’t have any clue about security, then throw it back.
The developers would curse at the operations guys who are just trying to give them a hard time, make a few minor changes, and throw it back.
Finally, the operations team would take the code, deploy it to the server, everything would break, and everyone would blame everyone else.
Ok, perhaps I’m being a little dramatic here, but the point is that we used to have very disconnected teams in the world of software development.
In the past—and for some organizations still today—it used to be that developers would write the code, and operations would take that code and deploy it without either team knowing much about what the other team did.
This did create a large amount of problems, but the problems were bearable until Agile software development came around.
Now teams are shipping new code once, twice, sometimes three times a week instead of every six months or so.
Development teams are building the code multiple times a day and running automated tests and quality checks against the code.
Things are no longer as simple as writing the code, building the code, and deploying the code.
Instead, a whole set of operations and procedures emerged as a way to be as agile as possible and to be able to move code quickly from development to production.
What Is DevOps?
Ok, so now that you know the backstory, what exactly is DevOps?
It’s the multidisciplinary process of getting code from development to production and taking care of the code when it’s there.
Instead of having two or three separate roles that don’t know much about each other, and are arguably hostile and antagonistic at times, DevOps is about taking full ownership at every step along the way.
In some organizations, there are specific DevOps roles where you might have a programmer who understands how to build and deploy the code involved in creating a build and deployment system to automate the process as much as possible.
In other organizations, the developer, tester, and operations roles are still separate, but they all work together to fill the role of DevOps through mutual understanding, cooperation, and collective ownership.
The important thing about DevOps is that it is a fundamental shift in thinking about how software should be delivered to production.
What This Means to You
Well, technically, as a software developer, you are part of DevOps.
Welcome. Congratulations. Here are your official DevOps wings.
Today, software developers are expected to know about more than just writing code.
You can’t get away with throwing your code over the wall and letting it become someone else’s problem, especially if you are working in a small company or startup.
You need to understand the process and tools that are used to move code from development to production—and ideally how to set up and use some of those tools.
Obviously, you should know how to use an IDE and build your own code locally; no one is going to do that for you.
However, you should also know how to use source control to check in and integrate your code into the other code in the system.
You should know the basics of continuous integration and how a build server works. (Don’t worry, we’ll cover most of this stuff in the upcoming chapters.)
You should know the fundamentals and types of testing and how automated testing of various sorts fits into the bigger picture of building and deploying the code.
You should know how an application gets packed up and ready for distribution or deployment.
You should understand the deployment process and how to automate moving code from a build server to a staging server or production server and how configuration is managed on various servers.
Finally, you should know something about monitoring an existing application to check for performance problems and other issues.
Yes, I realize that is a large amount of stuff to know, but you don’t have to have in-depth knowledge about all these things—and you don’t have to learn them all at once.
It’s more important that you know of and what these tools and processes are for, so that if you needed to implement parts of this tool chain yourself or assist in implementing them, you could.
Think of it this way.
Suppose you are a pitcher on a baseball team.
You don’t need to know everything about every position on the team, but it’s going to be difficult to talk about any kind of meaningful strategy if you aren’t at least aware of the other positions and what they do.
You don’t want to join a software development team and be completely oblivious to what happens after you check in your code.
And many software development teams don’t want to hire developers who are.
Like I said, though, don’t worry. I’m going to give you a basic overview of some of these topics in the upcoming chapters.
