Start a new development project on the right foot

In Web Development you will more than likely to go through the process of creating a new repository for a new application or project that you are tasked to build. It might become overwhelming thinking about all the different moving parts you need to set up, and what order they go in. We think it is really important to get the order of tasks correct at the start of a new application as this will greatly increase productivity and improve the solidity of the repository.

We have created a rough list of what order the tasks to set up a new repository should be done in. Obviously this is biased to our tech stack and the steps might have to be done differently. Take this list as inspiration and find out what works best for you.

This list was created through trial and error over numerous projects, perfecting it a little bit more every time.

 

1. Clone a template and remove pretty much everything

If you have a template to clone from, then use it. If not, then one of your latest projects completed with the same tech stack will do. Once the template has been cloned down or the existing project has been duplicated you should start by stripping out all the things that are not needed or need to be changed in the new project.

Here are some examples:

Change any API keys

This one is specific to if you duplicated an existing project. Most of these should be in an `env` file or something similar but there is some instances where this might not be the case.

 

Dependencies and super specific project files

Again this one is more for if you are duplicating an existing project. If your new repo contains code that is extremely specific to where it came from, then make sure to get rid of it. Make sure to take a look through the dependency files (`package.json`, `composer.json`) and remove packages that you definitely know will not be needed in this new project.

Do not be pre-emptive and try to add packages you think you will need, you can do this later when you actually know you will need them.

 

 

2. Take time to upgrade things

Since we now have a clean project with no “legacy” code this is an excellent opportunity to upgrade parts of the application and make sure we are fully optimised as we can be. This will make the application much more “future proof” and set it up well for future upgrades.

Here are some examples of things you could upgrade/tinker with:

 

Upgrading packages

This might be a good chance to look into getting that package upgraded that you could not have done so easily on the previous project. Especially if the current version of a packages is a major version behind, doing the upgrade now will save you a lot of time in the long run.

 

What could be done better

More specific to when you duplicate a project, but what does this repo currently do that could be done better this time around? Is the way the authentication set up not very good? Or have you got an idea for a reusable component that would make development way faster?

Try and think back to when you made the application you duplicated from and think of problems you encountered. Addressing these issues will make the development process a lot better this time around.

 

3. Set up development tools and CI

Setting up your development environment now as much as possible will put you in good stead for later on in the lifecycle of a project.

Starting processes like linting with Prettier – https://prettier.io/ ,code checking as you go with PHPCS – https://github.com/squizlabs/PHP_CodeSniffer, git hooks, and commit convention tools early on means that all of the code that goes into it will be correctly formatted and styled from the get go.

Also, setting up some kind of CI integration that will do things like run your tests and build your app for development/product deployment (see next step) is a good thing to do at this stage. Having CI also increases the stability and secureness of your application, so the earlier this gets sorted the better.

Here are some examples of development tools and CI that we use at Practically:

Conventional Tools https://github.com/Practically/conventional-tools/
Our very own creation, Conventional Tools is a CLI tool that allows you to do multiple things in a conventional way! From creating and tagging releases, to linting commits and allowing the ability to add your own pre-commit hooks

Prettier – https://prettier.io/
One of our go-tos at Practically. Prettier is a widely used linting tool for a multitude of languages. This links in really well with Conventional Tools because you can run Prettier inside a pre-commit hook

Psalm – https://psalm.dev/
Specific to PHP this one but if this applies to you we would definitely recommend [Psalm](https://psalm.dev/). An open-source static analysis tool that helps you identify problems in your code. If this interests you then why not check out our Yii2 Psalm Plugin which extends Psalm and adds better typing for Yii2 which is our PHP framework of choice.

 

4. Create a staging environment

Before any actual work begins on the code, the staging environment should be set up.

This is a good thing to do because once work does begin, it can be seen by people who need to see it straight away. If you are directly dealing with clients or just anyone that wants to regularly check the progress of tasks that are being completed then this is a must-have. Instead of having them bugging you for progress updates they can view the application themselves.

Setting up a staging environment mid-way through creating an application could also become a lot more difficult than if it was done at the beginning.

 

5. Commit everything

At this stage you should be ready to do the first commit to the repo. The first commit should just be something simple like:

If you are using Conventional Tools then don’t worry about the formatting. As long as it has the words “initial commit” in the text then it will recognise this as the first commit and will not lint it.

 

6. Start styling

At this point it’s a good chance to get the main parts of the styling done around the app. Obviously it depends on how you actually want to do styling but here’s some common things you can do:

– Set up styling variables, colours and themes etc
– Add logos and other assets to the repo

 

 

7. Data structure

Now it’s a good time to start thinking about getting some of the first tables in the database set up. Definitely do not try and get ahead of yourself and create structure you *think* you will need because it might change in the future.

Just create some basic ones for now, or maybe even the most important ones. For example, if you’re doing an e-commerce site then maybe you would create `{{%user}}` and `{{%product}}` tables first since they are depended on a lot by other parts of the application.

 

8. Build it

Now actually start building! Be amazing.

 

Conclusion

By doing the application creation flow in this order you are doing a lot of the leg work at the beginning by setting up the infrastructure that will benefit and support you in the long run. As previously mentioned, this list was created by Practically after starting new applications over and over again. Learning from our mistakes and being retrospective about what we could do better the next time is the main reason why we have come up with this flow that works super well for us.

Get in touch if you want more information or you want us to create you an amazing web application.