How we work

Lucas starts by pulling down the code base from the Cloud. Squiz keeps all of its clients’ code in secure repositories that require two-factor authentication to access.

Related resources

Git - branching model

Now Lucas can safely make changes to the code on his local computer, he does this by creating a version of the code based on the production code.

As Lucas is typing, the code editor is offering suggestions. This is the “magic” of a sophisticated AI assistant.

Lucas knows he wants to sort blog posts by date and as he finishes writing the function name, “sortByDate”, the AI assistant intuitively suggests the entire sort function allowing Lucas to accept the suggestion and in some cases make small changes and then rapidly move on.

Lucas feels happy to work a Squiz and have access to this tool.

Lucas realises he’s done a piece of work that’s valuable by itself, the blogs are now listed in the correct order. This is a signal to Lucas to push his code to the repository in the Cloud.

Small, focussed updates to his version of the code, called commits, are good practice. Lucas writes a concise and meaningful message to accompany his commit. Boom! His code has landed in the repo (short for repository).

The code now starts its own journey, as it lands in the repo it’s automatically scanned for potential problems, a process called linting.

In addition, it’s also scanned for spelling errors and a whole bunch of other stuff, but we’ll get to that later. If the scan fails the code can not be merged into the main version of the code. For this commit, the code passes this phase. Hazar!

As Lucas continues developing he notices he needs a “call to action” for the homepage. Not a problem.

Because Lucas works at Squiz, he has access to high-quality pre-built components. Lucas downloads the necessary component from the internal Squiz Marketplace.

Now, within minutes Lucas has the 80% of the “call to action” UI done. A few colour tweaks and padding changes and it’s ready.

Related resources

Internal Squiz Marketplace

With the “call to action” done, Lucas commits and pushes the changes to the repo. Again, the code is subject to automated checks, this time errors are found and the code cannot progress until they are fixed.

Lucas reads the errors and acts on them:

1. There are some accessibility issues around colour contrast
2. Some of the formatting is inconsistent
3. There are some minor Javascript errors

Lucas fixes the errors and pushes the fixes, again with meaningful commit messages.

The code passes the automated checks now and Lucas is feeling confident the changes are solid. He can now deploy his working changes to Matrix, he jumps into the testing environment and confirms the changes are working well.

Now that Lucas is happy with the changes it’s time to get others to look over them. It may seem like a lot of checking and validation but Squiz has tight processes to prevent bugs in production.

Before the changes can go live, Lucas needs to get approval from two people, a colleague or peer and the client.

Lucas creates an official request to merge the feature he has been working on into the production code. This is called a Merge Request. Thanks to the awesome tooling at Squiz this is dead easy for Lucas to create and he can even put comments on complex pieces of code or areas that he thinks need explaining.

Related resources

Creating a merge request

Alongside the Merge Request (MR), Lucas contacts the client using the ticketing system Squiz use and asks them to review the changes on the staging environment. Lucas provides clear instructions on how to view the new feature and makes sure he has met the acceptance criteria.

Related resources

Client approval

Now Lucas can move the ticket into the review column knowing that the client is reviewing the changes and someone in his team will review the MR.

Mia, who works with Lucas, picks up the MR and reviews the code and also checks the testing environment. She adds some comments to the MR but finds nothing that is crucial. She marks the Peer Review as Passed.

Mia does not merge the code yet since the client is still checking the changes.

Related resources

Reviewing a merge request

After lunch, Lucas notices the client has responded on the ticket:

“Looking good, love the changes. Happy for this to go live.”

Awesome, now Lucas has approval from Mia and the client. He merges the changes into the main branch of the code and yet again, it’s subject to automated checks, this time more stringent. Strict as the checks may be the code passes and is successfully merged.

Lucas runs the deployment process from the Gitlab interface. The process creates a release tag in the codebase, now the production environment can be associated with this new tag.

The changes safely go live!

Related resources

Learn more about deployment

Lucas opens the production site and smiles as he sees his hard work enter the world.

Five o’clock already, Lucas shuts his laptop and heads home, he struts confidently to the bus stop feeling a sense of accomplishment.