On the Zend blog there's a new post that looks at one of the major steps when you start to think about automation in the deployment of your application - continuous delivery.

For many, the process of manually developing and deploying software to production is archaic at best. Even in highly automated software development environments, at least one developer (although often more) typically manages modifications to code and software products, and the ramifications of these modifications can be extensive or unknown. [...] The emerging process for developing and deploying applications of high quality is one that is highly automated, executing continuously, and covers the entire development process, from modifying code through testing to deployment. Automation provides analysis that flags code for improvement and executes full regression tests every time a modification is made.

[...] This process is called continuous delivery, and automation is a key component of a mature continuous delivery process, which includes: continuous integration, infrastructure automation, and release automation.

After the introduction, they get into some of the basic concepts of continuous delivery and what kinds of steps can make up the full process. From there they get into some of the benefits of its introduction including lower staffing costs and enhanced teamwork. They balance this out with two barriers that could prevent adoption - the initial cost and the organization culture considerations that would need to change.

In his latest post Cal Evans reminds us, as software developers, that our jobs aren't always about making the things we create about the best code or most tech. It's also about having empathy for users of the software you're building.

I learned something very important in all of [the troubles I had with traveling to Amsterdam], I learned that we as software developers and designers need to have a great deal of empathy for the people using what we build. It is not enough to put yourself in your user’s shoes, you have to put yourself in their mindset. You have to design every user interaction with an understanding of not only who is using your software, but why they are using it.

He focuses the rest of the post on his experience post-delay, trying to get an update on where in the world his luggage might be via a URL given to him by the lost luggage group. He comments on the terseness of the message he was given on the page ("Delivery Initiated") but points out that it's not overly user-friendly and really doesn't give much information. He suggests that the developers of the tool didn't actually think about end users, just that they should share a status and that's all.

It is not enough to create personas and figure out who is using your software. You need to understand why they are using it, and what their mindset will be when they are using it. You need to have empathy for your users.

Luis Atencio has posted the latest article in his "Continuous Delivery" series today, this time with a focus on implementing a testing strategy. This is the fourth post in the series (part 1, part 2 and part 3).

There are three things in life that are always held to be true: we will die someday; we will pay taxes; and software will have bugs.... LOL [...] A testing strategy is often overlooked in software projects. This should not be too surprising, we want to build applications quickly and release them quickly. However, leaving quality out of the picture or towards the end are terrible mistakes.

He talks some about the different types of testing that revolve around software development - "business facing" and "technology facing." These are each split down even further into things like acceptance, integration and unit testing.

Luis Atencio has posted the third part of his continuous delivery series (parts one and two), this time with a focus on continuous integration as a part of the process.

This is a continuation from my previous post and overall the series on Continuous Delivery. If you haven't been following, that's okay, every topic is self-contained, so read along. The contents of these posts are taken from the book titled "Continuous Delivery" by Humble and Farley (resources below) overlaid with my own professional experience. In this article, we talk a bit more about Continuous Integration (CI) and some practices developers should follow to ensure a smooth environment.

He talks some about what "continuous integration" is and how much it relies on an automation of the process around your delivery of software. He mentions integration of testing (unit/acceptance/integration) and how it can help discover issues early. He includes a list of essential practices that come along with the idea of CI integration including:

• Don't check in on a broken build
• Keep a stable build at all times
• Anticipate being able to revert your changes
• Using TDD
• Distributed Version Control

He also recommends using any downtime (like waiting on a build to "go green" again) to take a few minutes away from the code - it can benefit you and your code.

Luis Atencio has continued his series on continuous delivery with this second post. It focuses on the first step (and one of the most important) - keeping everything configuration-related in a version control system.

I will be continuing the topic on Continuous Delivery which began in my previous post: Notes on Continuous Integration; this time we will start looking at the first and most important step, Configuration Management. In the words of the authors (resource below): Configuration Management refers to the process by which all artifacts ... and the relationships between them, are stored, retrieved, uniquely identified, and modified.

He sets out four principles that can be used to set this process up in your workflow:

• Keep everything in version control
• Manage dependencies
• Manage software configuration
• Manage environments

Each point has an explanation and advice on what he's found the best way to implement the functionality. He finishes with a few other pieces of advice including avoiding branching in config repositories and having good communication practices with your ops team.

In a new post to his site Luis Atencio talks some about one of the things many development groups strive for but have a hard time achieving - continuous delivery of their application.

In the rapid changing software world of today, companies and individuals have come up with many methods in order to minimize the time to market gap, i.e the time it takes for your idea to materialize in production. Specially in the very competitive world of mobile and web applications. [...] We want our Operations team to be able to deploy correct and tested code in a manner that is automated and not stressful. [...] However, there is a down side to this: while it is important to beat the market and be innovative, it is also equally important to do this with a process that allows you to have a reliable product release.

He introduces the concepts behind "continuous delivery" and includes an illustration of how the flow would commonly work. He also mentions some benefits to implementing this into your project's flow including easy auditing and versioning, quicker deployments and the creation of a simplified, unified deployment system across platforms/environments. It's not without its challenges, though, so there's a bit of discussion about those as well.

DevShed continues their look at the creation of a PHP email program (as excerpted from the "Zend PHP Certification Study Guide") with this new tutorial focusing on the management of the emails themselves.

In this second part of a two-part article, you'll learn how to manage email headers when creating a PHP email program, attach a file to a message, and more.

In this part they cover some of the details about the structure of emails, how to add an attachment to an email (for both a normal file and images for an HTML email), as well as a mention of how email is delivered.

DevShed continues their look at the creation of a PHP email program (as excerpted from the "Zend PHP Certification Study Guide") with this new tutorial focusing on the management of the emails themselves.

In this second part of a two-part article, you'll learn how to manage email headers when creating a PHP email program, attach a file to a message, and more.

In this part they cover some of the details about the structure of emails, how to add an attachment to an email (for both a normal file and images for an HTML email), as well as a mention of how email is delivered.