By Darren Beale

If your company has a software development team that maintains your web application code, whether internal or external, you want to do due diligence and ensure that they have the level of expertise that your application requires. Unexpected downtimes or issues with your web app can mean major costs for your business. You want to ensure you are receiving, and will continue to receive, the best service possible from your chosen team.

Our first article dealt with evaluating some fundamental characteristics of a web development company: their history, experience level, and how they structured contracts. In this article, we’ll dig deeper into how to evaluate the operations and procedures of your web developers when it comes to DevOps including:

  • Hosting
  • Bug-tracking
  • Deployment methods
  • Code storage
  • Testing methods

Hosting Configuration

One of the most basic questions to ask of any coding project is: Where and how is the code being stored publically so that your users can access it? (In other words, how is it hosted?) Improperly set-up hosting could lead to one or more of the following issues: the code is insecure and accessible by others; the code or code updates may be lost; or your company is paying too much for hosting.

Here are some subjects to ask your web developers about to get clear on potential hosting issues:

Type of hosting: There are many ways to implement hosting. Hosting can be done on premises (although this is to be avoided unless you have a dedicated IT team, redundant internet connections, and a large budget) or it can be outsourced to the cloud. It can be done on one dedicated server or it can be done on a shared environment, where one server hosts many segmented, virtual hosting environments. You should try to get clear on how your application is hosted. Do they use Amazon or Google Cloud server space? Do they have their own unique on-premises solution? Try to get clear about their hosting procedures and find out how common and respected their configuration is.

Who is actually responsible for the hosting: Your developers will likely not actually host the application themselves; this is perfectly reasonable. They focus on what they are good at and outsource hosting to a dedicated team. That said, you should still have a good idea who they are using and be sure that you have the authority to discuss the account in their absence.

Capability and expense of servers: Different servers have different strengths. Some servers are very fast and able to handle multi-tasking well. These will be more expensive when rented (as is the case with cloud-based hosting solutions). Some are slower; these will be cheaper. Sometimes databases are stored on one type of server and web applications are stored on another type of server, due to differences in bandwidth and speed needs.

Ideally, you want to be using only what is necessary to do your job and do it well. It’s possible that your hosting solution is over-engineered, which will make it overly expensive. Then again, it’s possible your hosting is not up to your needs, which may result in long delays and occasional downtime.

Security: Ask about security systems in place. This can include physical security, such as building security and guards. It can also include virtual security, such as firewalls and the software security upgrades. It can also include questions of access: Who has access to the login info for the server? How are those who have access decided upon? Is there a tracking system in place to keep track of people who gain access? (These questions may be mainly important for applications involving sensitive data.)

Dependencies: Dependencies refer to applications and programs that depend on each other to function. For example, an application often depends on a database, and if it doesn’t have that database, it won’t work. There are many such dependencies between parts in the average application. For the more complex applications, there will be a dependency mapping that lays out how the various parts of an application interact with each other, where the parts are located, and what will be the effect if some of the parts go down. There should be a plan in place to minimize any problems related to dependencies, and therefore minimize possible application downtime.

Back-ups: Backing up data, as you probably know, is very important. How often are your files backed up? Not only that, how often are the back-ups tested to make sure that the back-ups are actually working and will work when needed?

PHP version: Make sure you are running the latest PHP, or at least a relatively current version. (That would be at an absolute minimum PHP 5.4 and preferably PHP 5.6, as of this writing in May 2015.)

Things To Double-Check

Here are some situations that mean you probably need to dig deeper for complete explanations as to why the hosting is being done that way.

  • Web Hosting seems too expensive. If you believe, after researching comparable hosting prices for your type of project, that your hosting costs are too expensive, it could be a sign that your hosting solution is overkill for your needs. Talk with your team about this possibility and get their input. There may be a valid reason for the costs (for example, your business requires 99.9999% uptime).
  • Web Hosting seems too cheap. If the hosting, on the other hand, seems very cheap in comparison to what you’ve seen out there, that is also a sign of a problem. It may mean that your hosting is not adequate for your needs and you may run into downtime or problems in the near future. Or it may be the cause of existing problems.
  • Web Hosting seems shoddy. There are many ways a hosting solution might strike you as unprofessional. One example: you log in to view your folder structure, and you have access to another company’s files! That would obviously be a very big red flag. If you notice something that bugs you, bring it up to your team; there may always be a legitimate explanation.
  • Team blows off your questions. There are many legitimate ways to maintain and store code, which is why these points we’ve raised are often indications that you need to dig deeper and ask more questions. But if your dev team gives the impression that your concerns and questions are not important, that’s a red flag in itself. A skilled team will always respect your concerns and address them politely and completely.

Code Version Tracking

It’s pretty much required these days to have some sort of version tracking system for your code. Version tracking gives a history of changes to the code. This is especially important when a program is big and when there are multiple workers dedicated to it (over time or simultaneously).

Ask your developers what their system for version tracking is. The most common one these days is Git (and its online incarnation, GitHub) but there are many other systems like SVN (still good) and CVS (old and not great).

Ideally, you’d like to know that your team is using a respected system, like Git. This would make it easier for you in the event you changed your supplier, or had another party (internally or externally) work on the code. If your web development team is using an unpopular version-tracking system (or, even worse, no system), this will mean you’re likely to run into substantial maintenance problems at some point.

Things To Double-Check

  • Presence of version control system. It would be unusual, and bad, if the software development team you’re using didn’t have some way to track changes to the code.
  • Quality of version control. It would also be bad if the company was using some outdated, extremely ineffective method for tracking changes. A company should not be using Dropbox, Google Docs, FTP, and especially not email to track changes to code. This is just asking for trouble.

Bug-Handling

How a web maintenance team handles and tracks bugs is also very important.

There are many bug-tracking programs on the market. (If you don’t know much about bug tracking, here’s the Wikipedia entry on it.) As long as a team is using a reputable bug-tracking system, that aspect is probably fine.

Much more important, though, is how bugs are handled. Having a great bug-tracking system is one thing, but a team then has to decide how to prioritize bugs and how to segment developer time into time spent working on new code or working on fixing bugs. This is where the strengths and weaknesses arise.

If applicable, ask your software developers how they decide how much time is spent on writing new code versus fixing existing bugs. You might ask them for a report from the last year or six months showing the time spent on bugs versus new code.

Ask them how they track the bugs. What software do they use? Is there a web interface that team members and visitors can use for reporting bugs? Is there a dedicated email address used for reporting bugs?

Not all bugs are equal, so ask them how they prioritize the importance of the bugs.

Things To Double-Check

  • Bug-tracking methodology. If a web development team doesn’t have a dedicated way to track bugs, that’s a bad sign. Email or a Google Doc is a very inefficient way to track bugs.
  • Dedicated bug-tracking. Bug-tracking is separate from requests for features. Your dev team should have a dedicated bug-tracking system. If they say they use the same system for tracking both project work and bugs then you might want to check that the bugs and feature requests are categorised differently for quick recall.
  • No real prioritization. If you can’t get a clear answer on the process they use for prioritizing bugs and deciding what gets coded first, it’s probably a sign that there is no process in place; that they just decide on the fly what needs to be worked on. If this is the case, you might suggest a catch-up call once every few weeks to handle shifting priorities.

Code Deployment

Deployment refers to the process of taking code and getting it in live and working, doing what it’s supposed to do. In the case of web based applications, deployment will probably getting the code working online.

There are some methods and strategies that make code deployment more efficient and more accurate. This is a complex area with many facets and possible implementations, so this will just be a quick tour.

Testing

What does your chosen dev team do to test new code solutions? There should be a testing environment in place, a sort of sandbox where the developers can make changes and get it working correctly before putting the code live.

Provisioning servers

Provisioning has to do with setting up the web application with everything it needs to run correctly. It also has to do with making sure that all of the requirements in a testing environment are also made available in the live application environment.

Scripted provisioning refers to having automated processes for setting up provisioning. Some popular technologies for this are: Chef, Puppet, and Ansible.

Continuous Integration

Continuous Integration (CI) is the practice and philosophy of integrating code changes to the master code very frequently. The main goal of CI is to prevent integration problems; when code is not integrated frequently, there can be major unforeseen headaches with trying to get everything to link up and work properly again. CI helps prevent this.

Ask your team where they are with regards to these ideas. Ideally, a supplier will have adequate responses and be able to explain how their methods of deployment ensure smooth delivery and minimize errors and downtime.

Things To Double-Check

Here are some warning signs that a team’s deployment process may be far from optimal.

  • Smoothness of releases. When a change is made to code, are you or the developers trepidatious about the change? Is there frequently some doubt whether the change will work? This is a bad sign that not enough testing is being done and that there may be issues with how code is being integrated.
  • Answers to deployment questions. If your developers have no specific responses to your questions about how they organize and deploy code, that is a definite red flag.

Summary

So far, we’ve talked about some high-level ways to understand your PHP maintenance provider and their quality of service. In the next article in this series, we’ll continue to give tips for getting more in-depth information about your development team.

In future articles, we’ll look at strategies for improving your PHP app, including implementing user feedback and tracking app usage.

And if You Need Help…

If you ever need any help or advice regarding your web development, PHP upgrades or ongoing support, please feel free to reach out and ask us for an opinion.

Who’s “us”? We’re Siftware, a firm run by me, Darren Beale. I’m a long-time PHP consultant turned manager and my team includes other respected PHP developers. Over the years, we’ve worked with a diverse client list, overseeing their PHP development and providing ongoing support.

Our service offering is laser focused and we only work with owners or managers of existing PHP applications. If you would like to find out how we can help you please don’t hesitate to book a free consultation.