Posts
-
Using Jenkinsfiles for Continuous Deployment Pipelines
-
Story Points Baseline
-
Getting started with Behat
-
The journey to Microservices
-
Testing as code
If the idea of deploying code to production makes you nervous, then this one’s for you.
Despite the fact that you may have just solved the latest business problem with the most elegant solution and the least amount of code, you know how it is when it comes to deployments and humans, we will make mistakes, we get things wrong and we break things. It happens.
However, the way we solve this is by improving processes, not blaming humans. Employing what we’ve learned, leaning on our own experiences and experts in the field, while implementing the best practices.
Martin Fowler wrote about Continuous Integration in September 2000, followed by a significant update in May 2006. He talks about conceptual ideas such as maintaining a single source repository, automating the build, testing in a clone of the production environment, ensuring everyone can see what’s happening and deployment pipelines.
These practices help to lay the foundation to why we should create pipelines as code and the approaches we should take. For example, version control is a very powerful tool. Keeping everything in version control means you can easily keep track of changes, review code and maintain a source of truth.
Read More »Given a new team or a team restructure, should you baseline? Do all teams point differently? Do the team need to baseline?
Do you need to align your pointing to be the same across teams? Should all teams point the same? Should teams be autonomous?
These are the types of questions that come up in newly formed teams that have a mix of experience with either agile or their peers.
Ultimately it should be up to you and the team. Teams should be autonomous. What works for you and your team is probably right. Nobody should tell you how to work, that is your job.
Read More »Behat is a test framework for behavior-driven development (BDD) written in the PHP programming language.
BDD is described by its creator, Dan North, as a second-generation, outside-in, pull-based, multiple-stakeholder, multiple-scale, high-automation, agile methodology. It describes a cycle of interactions with well-defined outputs, resulting in the delivery of working, tested software that matters. Whatever that means…
Behat is intended to aid communication between developers, clients and other stakeholders during a software development process. It allows the clear documentation of testable examples of the software’s intended behaviour. Behat test scenarios are written with Gherkin, a business-readable domain-specific language following defined patterns.
Don’t think of it as a tool for testing, in the sense of removing bugs, think of it as a tool for documentation and specification.
Read More »We’ve come along way, even in the past few years. We’ve seen huge advances in web technology.
We’ve all been there… It gets to the point where anything is better than the legacy code. Legacy code is any code without tests, that is understood by no one and is too fragile to change, even though the business demands more, the legacy code is impossible to maintain. It’s code that can’t scale and uses obsolete tech (PHP 5.5 anyone?).
Moving away from the legacy code is always a challenge. Do you simply replace it with another monolith and say “no, we’ll definitely get it right this time”, or do you take a different approach?
Read More »In a time where DevOps culture demands “everything as code”, from infrastructure to monitoring, its about time we took “testing as code” seriously.
First of all, I’m a big fan of test-driven design (TDD) and unit testing, but I’m not just talking about unit testing here. We already know unit testing should always done by a unit testing software framework, (usually) written before the code, and is always written in code.
Beyond this type of functional testing, you venture into feature testing. Testing the integration layers, and end to end testing, probably manually. With automation as the goal, you really want to focus on how you approach testing and give some consistency across it all.
There’s a number of principles and practices that lend support to the idea of this “testing as code” approach, including continuous integration, automation over documentation, automated testing, version control and infrastructure as code. Ultimately, it’s about making testing less painful.
Read More »subscribe via RSS