Jay Myers, Software Engineer
February 2, 2015
Broken builds and deployment problems are two of the monsters that haunt the lives of software developers. But will these common problems soon be a thing of the past? Or have they already been relegated to the history books? In this blog post, a Strasz software engineer discusses the merits of the company’s continuous integration efforts, and how they make monsters disappear before they rear their ugly heads.
As a software developer, the majority of my time is spent providing solutions to problems. On a good day, they’re the kind of problems that, once solved, produce valuable, tangible results and effective, functioning software. On a bad day, though, I am faced with problems that, even when solved correctly, are unsatisfying. These include problems that we’ve solved already, but whose solutions have been incorrectly implemented or inadvertently broken. Problems whose solutions provide no new value and only shed light on the fact that human error is an inevitable consequence of any manual process.
When I think about the bad days, there are two such problems that immediately come to mind. Two unspeakable evils that haunt the dreams of developers everywhere. Two monsters whose days of tyranny and oppression are, thankfully, coming to a close here at Strasz.
The first of these is the infamous broken build, or programming code that, for one reason or another, will simply not compile correctly. When other developers on the team try to merge their changes with this broken, battered, bruised, and busted solution, development stops. Emails begin flying around, asking everyone to drop what they are doing in order to solve the problem. Eventually, after the problem is resolved, an all-clear is sent out and life slowly returns to normal. But at what cost? An hour of development time for the whole team — plus the cost of people losing their train of thought and switching over to damage control mode — is no small matter.
The second of these problems is even worse. It’s a monster that waits just below a seemingly calm surface, waiting to emerge and swallow unsuspecting development teams whole. It is the set of maladies collectively known as deployment problems. Imagine that it’s late on a Friday and most of the team has gone home. It’s your job to ensure that the entire team’s production code is successfully deployed into the staging environment. You perform the proper steps and start up the application. And….nothing. You can’t log in. The lone QA staff member who has stayed late with you can’t log in either. After two hours of investigation, you realize that the server’s configuration file has an incorrect setting tucked away in its vast labyrinth of XML nodes. You quickly make and validate the change, and head home several hours late, making a note that you must remember to buy lunch for that generous QA staffer.
Is there no hope? Of course there is! In fact, both of these problems can be mitigated with the same solution: a magical remedy called continuous integration.1
Perhaps you’ve already heard of continuous integration, mentioned as part of extreme programming2 or in some other similarly intimidating context. Maybe you’ve heard that it costs a lot to implement and you’re wondering if it’s worth it in the long run. Well, if my tales of woe do not shake you to your core and prepare you for immediate action, then nothing will. But truth be told: continuous integration can make your monsters disappear before they rear their ugly heads.
Continuous integration is, briefly, the practice of having developers merge their code into a single integrated stream that is continuously built, tested, and deployed. This can be set up in most modern version control systems, and Strasz’s Team Foundation Server3 (TFS) is no exception.
In fact, our TFS system is set up so that, upon check-in, all code is built, tested, and deployed immediately. This build and deployment automation also goes for each set of environments used in development, testing, and software delivery; when we are ready to push to our QA and UAT environments, it’s all automated at the click of a button. All tests are re-run to validate functionality, and everybody gets the warm and fuzzies.
What all this really adds up to is a lot more good days than bad. Which frees me up for more important things…like another cup of coffee.
FOOTNOTES:
1. Learn more at http://en.wikipedia.org/wiki/Continuous_integration.
2. Learn more at http://en.wikipedia.org/wiki/Extreme_programming.
3. Learn more at http://en.wikipedia.org/wiki/Team_Foundation_Server.
Jay Myers, Software Engineer
February 2, 2015
Broken builds and deployment problems are two of the monsters that haunt the lives of software developers. But will these common problems soon be a thing of the past? Or have they already been relegated to the history books? In this blog post, a Strasz software engineer discusses the merits of the company’s continuous integration efforts, and how they make monsters disappear before they rear their ugly heads.
As a software developer, the majority of my time is spent providing solutions to problems. On a good day, they’re the kind of problems that, once solved, produce valuable, tangible results and effective, functioning software. On a bad day, though, I am faced with problems that, even when solved correctly, are unsatisfying. These include problems that we’ve solved already, but whose solutions have been incorrectly implemented or inadvertently broken. Problems whose solutions provide no new value and only shed light on the fact that human error is an inevitable consequence of any manual process.
When I think about the bad days, there are two such problems that immediately come to mind. Two unspeakable evils that haunt the dreams of developers everywhere. Two monsters whose days of tyranny and oppression are, thankfully, coming to a close here at Strasz.
The first of these is the infamous broken build, or programming code that, for one reason or another, will simply not compile correctly. When other developers on the team try to merge their changes with this broken, battered, bruised, and busted solution, development stops. Emails begin flying around, asking everyone to drop what they are doing in order to solve the problem. Eventually, after the problem is resolved, an all-clear is sent out and life slowly returns to normal. But at what cost? An hour of development time for the whole team — plus the cost of people losing their train of thought and switching over to damage control mode — is no small matter.
The second of these problems is even worse. It’s a monster that waits just below a seemingly calm surface, waiting to emerge and swallow unsuspecting development teams whole. It is the set of maladies collectively known as deployment problems. Imagine that it’s late on a Friday and most of the team has gone home. It’s your job to ensure that the entire team’s production code is successfully deployed into the staging environment. You perform the proper steps and start up the application. And….nothing. You can’t log in. The lone QA staff member who has stayed late with you can’t log in either. After two hours of investigation, you realize that the server’s configuration file has an incorrect setting tucked away in its vast labyrinth of XML nodes. You quickly make and validate the change, and head home several hours late, making a note that you must remember to buy lunch for that generous QA staffer.
Is there no hope? Of course there is! In fact, both of these problems can be mitigated with the same solution: a magical remedy called continuous integration.1
Perhaps you’ve already heard of continuous integration, mentioned as part of extreme programming2 or in some other similarly intimidating context. Maybe you’ve heard that it costs a lot to implement and you’re wondering if it’s worth it in the long run. Well, if my tales of woe do not shake you to your core and prepare you for immediate action, then nothing will. But truth be told: continuous integration can make your monsters disappear before they rear their ugly heads.
Continuous integration is, briefly, the practice of having developers merge their code into a single integrated stream that is continuously built, tested, and deployed. This can be set up in most modern version control systems, and Strasz’s Team Foundation Server3 (TFS) is no exception.
In fact, our TFS system is set up so that, upon check-in, all code is built, tested, and deployed immediately. This build and deployment automation also goes for each set of environments used in development, testing, and software delivery; when we are ready to push to our QA and UAT environments, it’s all automated at the click of a button. All tests are re-run to validate functionality, and everybody gets the warm and fuzzies.
What all this really adds up to is a lot more good days than bad. Which frees me up for more important things…like another cup of coffee.
FOOTNOTES:
1. Learn more at http://en.wikipedia.org/wiki/Continuous_integration.
2. Learn more at http://en.wikipedia.org/wiki/Extreme_programming.
3. Learn more at http://en.wikipedia.org/wiki/Team_Foundation_Server.