Without monitoring, server changes can’t be analyzed to see you’ve really made things better (or even worse). And without testing, every commit you make is a risk to the running site.
Click to continue…
Starting a job with a running system and real users is a nice “problem” to have but it presents some unique challenges as well. Especially if server monitoring isn’t robust and there are absolutely zero automated tests. Without these two critical components, you’re both operating and developing completely blind.
Kevin Parker
This is an interview with Kevin Parker (@kevinparkerusa) about DevOps
How do you see agile affecting application development and delivery?
The biggest impact is that application development teams are using agile to speed up their delivery of software changes and updates. This makes the developers happy as they can get through requests faster. However, releasing that software out to the organisation is different: small teams are responsible for their own releases, while larger organisations have dedicated staff that handle getting software out to the business.
Whatever size you are, the increasing number of releases will have an impact on the overall process. One customer I spoke to recently has taken up agile, and gone from 50 releases per year up to 350. That is a huge increase. While the amount of code might be smaller, the change procedure will be the same, and that puts pressure on the overall application delivery process and the staff who release the software. This introduces the risk of there being undiscovered errors in the release. And that might mean production outages.
Click to continue…
Today was a great day. I helped import our entire “roadmap” of functional requirements from an Excel spreadsheet into Pivotal Tracker. Even though we allocated almost a half-day to accomplish this, it was done in less than two hours (including in-depth descriptions and backgrounds on many features I hadn’t yet seen).
The product manager’s eyes lit up when I showed him how priorities were set (drag & drop, top story rules) and how easy it was to add screenshots to stories (again drag & drop). He spoke often about the pain that spreadsheet caused him and the entire team. Ironically enough, just before we were to sit down and do the migration, he realized he’d lost the changes to the spreadsheet made last week in the team meeting! A fitting farewell from an overly abused project management tool.
Click to continue…
This is a guest post by Brian Doll, Application Performance Engineer at New Relic
Six seconds can be an excruciatingly long time to wait for a single web page to load. Why does it take so long? Let’s take a look at each step of the timeline and see how we can make it faster.
Page load timeline.
Click to continue…
Consider the following: People are complicated and companies are run by a lot of people. A relationship between two people is complicated. Relationships between companies? Well, you see where I’m going.
Outsource a software development project requiring 10 developers, an on-site team of 3 managers and 4 developers, involving a total of 4 external companies. Surprised that the shipped product is more complicated than you originally planned? You shouldn’t be.
Click to continue…
One of the most challenging things about introducing Agile in the workplace is that it’s not very widespread. People have heard mixed reviews about it’s implementations, and are hesitant to exchange the known (no matter how bad it may be), for the unknown. More and more companies, however, are adopting Scrum for their project management. The “scrum flu” usually starts in one department, and, if implemented successfully, begins spreading throughout the rest of the company. Nevertheless, kicking off any form of Agile Development for a team with no prior experience in Scrum, Kanban or even XP, has to be done with thoughtful deliberation since a poorly managed migration can quickly result in disillusionment.
Here are a few technical steps which have to be made before you change project management styles.
Click to continue…
Scrum defines a set of required meetings: Sprint Planning, Daily Scrum, Scrum Review, and Scrum Retrospective. Additionally, there might be a Scrum of Scrums, if you’re running multiple Scrum teams in parallel. If you’re doing two week sprints you spend at least half-a-day per week in Scrum meetings. Isn’t that a lot of additional overhead?
Click to continue…
Click to continue…
It’s been a while since I talked about how we develop and deploy software at my current job. It’s come a long way from the “Good Ole Days”, when cowboy coders manually FTP’d their changes to the master server and rsync came along 5 minutes later to replicate the changes to the slaves *shudder*. Keep reading below for the details.
Click to continue…
You know it within an hour of working with them. A special kind of sysadmin or developer that not only knows how to do their job, but really cares about doing it right. This is the person that makes you refactor that duplicate method or add that one last test. The kind of engineer that dots every i and crosses every t. David Lutz (@dlutzy) tweeted this last week “Of the IT professionals I’ve worked with, talented sysadmins and programmers, only a select few are worthy of the title Engineer.”, which really struck a chord with me.
Click to continue…
This is a guest post by Boris Gloger (@borisgloger)
A couple of days ago I commented on Matthias’ post about the myth that Scrum forces a team to release new functionality only after a sprint is finished while Kanban would is more flexible.
I wanted to know the difference between Scrum and Kanban, and why people start to blame Scrum as the enemy saying that it’s too disciplined, too inflexible, and, and, and… So, I attended David Anderson’s intermediate class about Kanban.
Click to continue…
