Getting your site from concept to the public is technically the “easy part”. Ensuring that it continues to function as intended is what I’m going to talk about today, and give you a little bit of insight on why our process ensures that your website keeps working well with each update.
First and foremost, we keep your site development in-house.
All of our developers are all highly educated in their areas of expertise, work in-house, and are always provided with resources and schedules for continuing education in their field. This excellence carries right over to your site, your applications, and your portals. The code we produce is version controlled and managed via remote Git repository, and we are able to make sure it remains clean, organized, current, and highly secure throughout the life of each project. You will not find that level of organization with companies who promise to get it done ‘fast and cheap’ due to outsourced work.
What is Git? Git is an open source distributed version control system designed to seamlessly handle web development projects of all sizes with speed and efficiency. It also provides superior integrity management with The data model that it uses. This “ensures the cryptographic integrity of every bit of your project. Every file and commit is checksummed and retrieved by its checksum when checked back out. It’s impossible to get anything out of Git other than the exact bits you put in.” -Git-scm.com, the official Git information domain. |
We use the Gitflow process, which is excellent for a release-based software workflow. Gitflow offers a dedicated channel for hotfixes (ad-hoc fixes) to production, and can be summed up as a workflow that defines, and makes use of a strict branching model designed around the project release. The Gitflow process provides a robust framework for managing larger projects.
Gitflow is ideally suited for projects that have a scheduled release cycle and continuous delivery through automation. To learn more about the technical ins and outs of the Gitflow workflow process, Atlassian has a great explanation here.
The Instance of Instances
An instance can be viewed as a checkpoint area. It is very risky to make edits and run software updates to your live site without first testing to see that they will function correctly and as intended. Development and staging instances help identify weak points in security, as well as functionality that doesn’t sit quite right so that these can all be solved before going live in the production instance (or live site).
For every project, there are three major types of instances:
Production – This is the currently released version of the application. It is accessible to the client/end users, and typically does not change except for during scheduled releases.
Staging – This is normally a mirror of the production environment. The staging area contains the version of the application that will come next, and is used for final testing and approvals before going live to the public.
Dev (Developer-Specific) – Developer instances run inside Docker containers on our local workstations. This is where updates and other feature enhancements are completed. All work is committed to ‘feature’ branches which can be merged upstream once approved. 
When ready for deployment, the feature branch is pushed to our remote Git repository. The feature branch can then be “checked out” (kind of like a library book) on the staging instance for testing and approval. Once code has been approved on Staging, the feature branch is merged into various higher level branches, and a new release tag is generated.
Lastly, the production instance is brought up to date with the new tag, which incorporates the latest code updates, and provides a versioning system that allows for fine-grained control of the state of the production codebase.
About Docker Simply put, Docker is software that makes running applications inside a container within an operating system lightweight and cross-platform friendly, so that no matter which developer “opens” the container, the exact same instance of their application is available to work on. This virtually eliminates hiccups that can occur from local machine to cloud and back again, thus making system-specific troubleshooting a thing of the stone ages. |
Why the CommonPlaces Approach to Web Development?
You’ve learned a little about our approach, the tools we use, and how we structure our projects, but that doesn’t really tell you WHY it’s a good choice to use a trusted developer rather than just going it alone with a DIY platform such as WordPress. I’ll answer this one with one word: Security.
Okay, there is functionality too. Ya’ got me. By keeping your staging, testing, and live site all in one containerized environment, you are ensured that everything on your live site, including security updates, will completely match everything that has “gone right” in your testing environment. To learn more, schedule a Web Development consultation with CommonPlaces today.
Related Article: Learn about the best reasons to use a trusted developer.
