---

This is a general outline of the project workflow at Grafite for both our own apps, open source code as well as our clients projects.

Project Discussion

The process always starts with a variety of discussions involving all the project’s main contributors. Notes are collected and reviewed from these discussions before the actual development work is done. Once there is a collective agreement on the project details and budgets, we begin the development cycle.

Development Cycle

Once we’ve finalized the plan, we kick off with a repository. If the project is open source, we set up Travis-CI.org for continuous testing. If the project is private then we’re off to CodeShip.com to set up a continuous delivery configuration on that. We build our servers with Laravel Forge on whichever platform is best suited to the project’s needs. As we develop new parts of the project, we push our code off to the CI tools to run the tests. In the case of private projects we will then trigger a deployment by Forge to the servers. In the case of open source, once the Github tests come back successfully we version tag the package and release them, which in turn updates Packagist. This processes ensures that only successful builds of projects and packages are being deployed.

For any projects that require that we manage the hosting of we set up a profile for the project on Mission Control and then set all exceptions to be logged through it. Then update the servers to report data back to Mission Control so we can be alerted through Slack when issues arise.

For nearly all projects and open source code, we will integrate a code quality analysis tool. This can provide us feedback on what should be our next focus in the development cycle. The analysis is not intended to impede delivery as code quality is a service done for the sake of improving the code and making it more maintainable, it rarely impacts the server’s ability to process the code effectively.

In the case of client work, we’ll often run a staging server configuration which replicates production in order to test the impact of any customer facing changes. Our QA team will do thorough review of the features, and report back any issues they encounter to Github. This gives us three incoming streams of issues, between Mission Control, code analysis, and QA reporting issues on Github. Once issues are reviewed and tagged as tasks, we’ll do our best to address them in a reasonable timeframe.

The entire process relies heavily on constant communication with our clients or our own internal teams. This is not just to report back findings, but to keep a constant analysis on task priorities.

This process is never a final static flow, its been under constant change from day one, and will likely continue to change. But the core remains the same: set a plan, build, deploy, review, refactor, deploy… A good evolutionary process will let the details change but the core process remains the same. Find a flow that works for your team, but never let it be the one and only option.