Lamp Bristol Ltd
Responsive websites, APIs & Applications

Our Process

Plan, Develop, Test, Deploy!



Plan, Deploy, Test, Develop.




Before any development work begins we need to understand your business. We will write a summary of the business, any special acronyms or technical elements will be noted. This will help us create a glossary of information, making it easier to communicate with your team. During this time we will also help you to fill out the brief for the work. For example, this could be working out what your MVP (minimum viable product) is for launch or what your budget allows for when rebuilding your application.


You might have already created these for your project if you've gone through a round of UX or carried out internal testing. If you haven't, we will work out who all the stakeholders are of your application, from Sarah the super admin, down to Roger the registered user. In all documents and meetings we will refer to these specific personas when trying to create a feature, solve a problem or write a test.

Chapters & Stories

We can now start to break your brief up into chapters and stories. A chapter might be "Setup Authentication" and a story within that would be, "Roger can log into the site". Chapters and stories will become very detailed with longer user flows for more complicated tasks. These stories then act as tests for us to achieve and for our clients to sign off. So if Roger can't login then that piece of work is not finished.


Within each story there are many tasks to complete. In the initial chapters and stories the list of tasks are usually longer than the tasks of stories in later chapters. This is because when we're first starting out on your application nothings has been built yet, so all the initial front-end development of forms and pages, and all the backend services for elements like authentication are yet to be created. Tasks within stories might look like: 

  • Frontend - setup twig template for login page
  • Backend - create symfony login form for login page

Our clients have access to all tasks we write under our stories, we like to be transparent in what we will be producing. Also if you stop the project after the planning stage you will have a full technical specification for your project when you come to re-starting it. 


Once all of the above is done, we can methodically work through the chapters, stories and tasks putting times against them and provide a solid cost back to our clients.



Sorting out the environments we will ultimately deploy the project to and the environment for the developers to work on is one of the first things we do. Doing this upfront reduces risk; we know from day one what we've written works on out target environment. 


For our standard projects we will have a local development environment using Vagrant and Virtualbox on our own machines. We will then have a staging environment that we can test new features on before they are deployed to our live environments. Of course if you require more stage environments or demo environments we can easily meet whatever your business requirement is for testing and sign-off.


We use Ansible to provision and deploy to all our environments. This allows us to share exactly the same development environment throughout the team, and know that our development environments match the stack on the staging and live environments.

one click deploy

Tasks like provisioning servers and deploying a new release of code can be complicated. We create scripts to do these tasks. Want to deploy a new version of the code, we'll have a single command to run. If new developers need onboarding onto the project they'll be able to set up a fully working local environment with a single command.  



If it isn't tested, it doesn't work

Testing is a mandatory part of software development. Only code that is known to work it code that is tested (and that can mean manual testing). Testing is seen by some as boring and time consuming. To counter that we automate as much testing as possible. The full range of testing is covered from unit tests to system tests. 

well tested code enables change

Business requirements change all the time. Sometimes the driver for change is understanding the market better, other times it's in response to competition. Whatever the reason functionality needs to change too. A well tested codebase makes change easier. New tests are added or existing tests are updated to reflect change to requirements, all other tests remain the same. If the test suite still runs after the updates to code we know that in making out changes we've not broken any existing functionality. 

continuous integration with Circle CI or Jenkins 

Our full tests suites take anything from a few minutes to half an hour to run. When developing we don't want to wait around for tests to run, we want to get cracking coding up features. Typically we'll run the tests related to the area we're working on and then push out changes up to our Continuous Integration (CI) server. The CI server runs the complete test suite and other code quality checks. Only if all those pass will the code make it into our deployable branches. 



Keep the code clean

We strive to keep our code clean by following many of the practices recommended by the industry leaders. We have frequent discussions and often bounce ideas off each other to ensure the best approach to complicated problems. 

every line of code is checked by another developer

Code review is used on all project. This means every line of code written is checked by another developer. This keeps the quality of code high and also means that developers other than the author are aware of what's going on.  

developing the developer

All out developers attend at least one conference a year to keep them up to date with the latest technology and best practice.