You are viewing a read-only archive of the Blogs.Harvard network. Learn more.

Cloud Delivery Platform — Thought Model

October 24, 2014 — JaZahn

I was asked to take a look at a thought model for a Cloud Delivery Platform. I’m not going to post that graphic, because it wasn’t ready for prime time. It was confused and I’m not really sure what it was trying to show. So I created a bit of a diagram showing what I thought was important. (Just click on it, it doesn’t seem to fit right, and the next size down is too small to read.)

cloud_delivery_platform

Halfway through I realized I’m not terribly good at making these things. I’ll get better. But there’s a few things I wanted to draw attention to in this graphic.

The Roles

This was the most important thing to me is to highlight the crossover of roles for each step. There are few steps in the process that should be perfomed by a single role. Devops is about communication.

Local Development

Coding, building, testing, packaging are all things that should be done at the same time. You don’t code 1000 lines then build. You build with every small change. In the same way, you should have tests written with the small increments. And that gets extended to “packaging”.

Packaging

I’m probably missing a very important word in my vocabulary here, but I’m going to go easy on myself, it’s late. What I’m meaning here is the process of setting up an image, or a deployable product. The configuration that will collect external dependencies and run tests when it gets to the deployed environment. This should all be done locally first. It should all be put into version control, separate from the application code. And this needs to be done in collaboration between the developer, who knows the application, and operations (or as they’ve been renamed in my organization, “Devops Engineers”) those who know how to package things appropriately.

Local Concurrence vs Cloud Linearity

Why isn’t spell check underlining “linearity”. That can’t be real. As I mentioned before, the things done locally are all done at the same time (build, test, package). That’s all just development. When it gets to the cloud, it’s a done product. Nothing should be further developed there. Nothing should be getting reworked. Everything needs to come entirely from Version Control and no manual finagling. (obviously?) So the cloud portion is linear. Everything happens in order. If it fails at any point, it’s sent back to local dev and fixed there.
Maybe this is all so obvious, it doesn’t need to be said. Maybe I’d feel better if it were just said anyway.

Posted in Continuous Integration, Uncategorized, Version Control. Tags: , , , , , , , . Comments Off on Cloud Delivery Platform — Thought Model »

Shame on Me: the missing code review (or is it unit testing?)

February 15, 2014 — JaZahn

So a bug was reported not long ago. Let’s say “sensitive data” was available where it shouldn’t have been. I had an API view, a view that was returning json only, or should have been. Apparently early on in the project, I had added a comment to that view, to make sure it was returning the appropriate data. So I had added an html comment to a view that was supposed to be returning json. And I had it outputting everything under the sun it could output. 

<!--
"secure data" => "stuff I don't want the user to see",
... 30-40 lines of this ...
-->
{"success": true}

So there’s 2 problems with that. The most important of which is that with DOM inspection tools, like chrome developer tools or firebug, you can inspect the return value of that request and see the data I don’t really want you to see. The other problem is that I’ve created invalid json, and whatever is checking that success is clearly not using that value.

Why did I do this?

This was early on in development and I was debugging the easiest way I could.

What could have prevented this?

A code review of any kind. One look at that file would have been a red flag to anyone. But a view file that was only outputting true or false never seemed like something I ever needed to look at once I got it working.

Posted in ATG, Javascript. Tags: , , , , , . 1 Comment »

Continuous Integration with PHP on Travis CI and Github

March 21, 2013 — JaZahn

People on high have been preaching the wonder of continuous integration for a while now. It’s been all about Jenkins forever. Jenkins is still the #1 choice for most people, but I recently ran into Travis CI and at least short term, this is going to be the solution for our shop.

What is Continuous Integration for PHP?

CI to most people involves building and running integration tests. PHP clearly doesn’t build, but good PHP still has unit tests / integration tests / functional tests — so CI for PHP is running those tests before code merges.

What makes Travis CI good?

Probably ease of use. There is no setup of a “travis server”. It’s a service that they run. You hook it to a repo you have access to and set up a config file and it’s good to go.

But this only works with github?

That’s probably the biggest detractor. It’s currently built exclusively for use with github. Which is awesome for github projects, but not every project can be on github. We don’t always have control over where our repos are — and not everyone is an open source person.

Posted in Development, Open Source, PHP. Tags: , , , , , . Comments Off on Continuous Integration with PHP on Travis CI and Github »

Functional Testing: what to test?

July 5, 2012 — JaZahn

I’ve been working with PHPUnit’s SeleniumTestCase. I worked out some good login switching for the two authentication schemes I’m working with. Then came time to actually write some tests. But what to test?

Unit testing tests a single class. A singular piece of code or a unit. I typically write unit tests for Models only. Integration testing tests the interaction of multiple units or units with multiple resources. I’ve been thinking of these as sort of testing the Controller. That’s a little simplified, but it’s not really something I have a framework for with Yii and PHPUnit. Functional testing likewise has varying definitions. Some people like to focus on the testing of “functional requirements of the product” and some people have a more simplistic view of it, that it’s just automating tests of the views — so it can be used as integration testing. I personally think the former is a better way to look at it, but it also sounds a little douchey to say it out loud.

So I’m totally agile. I’ve got all these user stories. And all these tasks. What I’m doing is writing the functional tests in terms of the user stories and tasks. This is sort of BDD, except I’m ignoring the excessive mocking, which basically makes the BDD tests unit tests, and doing the whole shebang at once. Shebang isn’t being picked up by spellcheck. #!

Posted in ATG, Yii. Tags: , , , , , . Comments Off on Functional Testing: what to test? »

Behavior Driven Development Frameworks

June 10, 2012 — JaZahn

I’ve been going nuts integrating Behat into Yii because BDD seemed so cool. Behat actually provides a yiiextension, but I’m not proficient with phars (think php jar), so it was annoying to get it integrated with Yii.

PHPUnit_story was cool and convenient, but was deprecated in 3.5 and removed in 3.6 in favor of behat.

Upon further reading though, I made the realization that Behat is unnecessary and very much a waste of time. The developer is the only one who will be dealing directly with the unit tests, so by turning the unit tests into awkward-english is just obfuscation. It will make less sense to the person working with the code and adds a layer of work to the project.

I am not saying anything bad about BDD, but BDD doesn’t need a DSL to be BDD. The test methods can still be written for Behaviors and it will still carry with it all the BDD benefits.

RoR*’s Cucumber should also be mentioned. The RoR community seems to have really embraced the BDD framework Cucumber. It should also be noted that RoR community seems to set the trends for other framework niches. That being the case, maybe cucumbers are in everyone’s future.. but as of now, the practice has not caught on anywhere else. Behat is the least popular PHP lib I’ve ever worked with. JBehave is considered out there. Same with Python’s “Lettuce”.

* Opinion: I consider Ruby to be a hobby language. People don’t make real applications in RoR, they’re more academic with it. Which isn’t bad, I’m glad to see Java displaced as the academic language, but people actually do stuff with Java. Ruby is a fine play language, but people who do Ruby, are probably not doing anything real.

Posted in ATG, PHP, Yii. Tags: , , , , , . 2 Comments »
«
»