This article aims to tell the story of mature Ember.js projects, take you behind the scenes, possibly help you to deal with long-term projects with the team.

As a background to the main story, let me use a classic movie from the 70s - ‘Alien’ - directed by Ridley Scott. If you are not familiar with the storyline, it tells the story about the Nostromo ship and its crew. What does that have to do with Ember? Well, I would like to use the ship as a representation of a mature project and therefore, talk about the potential ‘enemies’ that can appear on our ‘ship’, how to prevent those attacks and how to ‘kill’ the enemies. To succeed, we need to find a Holy Grail that is going to help us save our project.

The first problem that we can come across on our ‘ship’ is chaos, decision chaos in particular. Introduction of good leadership is what can save us from falling into our enemies’ hands. To have the said good leadership, we need to establish one person who will lead our project, make the necessary decisions as soon as possible. In the case of product development, this person is usually the product owner, so we need to make sure that we have a single person of contact on the product owner’s team to avoid situations where two stakeholders have completely different opinions on the particular topic, hindering our work and introducing confusion. Do not hesitate to ask your customer to pick one guy who you will be contacting while working on the project.

Going back to the plot of our movie, at the very beginning of the film, one of the main characters - Ripley - is set on a mission to wake up the entire ship, wasting precious time. This is where we need to think about which processes on our project can be automated to save time. Firstly, we should automate system checks, CI environment setup, automate tests, deploys, linters as well as establish some templates for pull requests to avoid repeating simple tasks that consume energy and precious time that we can make use of somewhere else.

The next enemy that can pop up on our ship is simply breakage and malfunctions that can lead to our ship breaking down. In the world of projects ‘malfunctions’ means issues that pop up. The obvious thing to do is to check the current state of the ‘ship’, make sure that we know the current problems, issues, what work and what does not. Then, set the proper priorities to ensure that the most critical issues are handled. It would be nice to have a long-term repair strategy with upgrades and possible improvements. Another thing is, you should know your crew well, especially focusing on rookies since they are the ones that are the most prone to make errors. Prepare a training drill. Before the battle, you should establish some best practices for the team. In terms of Ember it is pretty easy since some guidelines are already in place.

Another important thing is to have a shipping protocol. In our case, it will be, for example, licensing. We should make sure that our dependencies have proper licensing, which does not harm Wasteland industry licenses policy so we avoid getting in trouble with the legal department. Keep in mind, it is quite easy to harm the team in the open-source world, so make sure to check twice. There is a possibility to automate the process with a proper npm package.

When you are traveling on a ship, especially in space, you should be aware of the unknown creatures and worlds you may come across. Do not be scared of them, be prepared. As far as projects go, you should never say you know enough or that something cannot be done better. There is always room for improvements, something greater can always be achieved. This is why we should experiment in a safe environment, if possible, or at least try to reduce the risk of potential breaks by having a staging environment to experiment with new Ember features or browser capabilities that can improve your application and amaze the future users.

It is also important to have a backup plan like a ship block where we store the documentation since operating a ship is quite complex. The guide should always stay up-to-date and we have to make sure all the information is stored there so we can be prepared for the worst case scenario. Imagine a situation that one of your crew members responsible for ship maintenance gets killed. You can always take a look at the documentation and figure out a way to get it done yourself. It is better to have more than one team member responsible for a single thing. This will help you deal with a possible staff shortage in an emergency situation.

Since we are more or less prepared for the big final battle we can bring one more weapon on stage. And what is the ULTIMATE LTS weapon? Testing! With proper testing, we can handle multiple actions automatically, especially on long-term projects. Tests allow us to refactor our code or project safely - it is just like rebuilding our ship. They also help us document everything, creating a passage map for the ship with the exact locations of various devices. Tests can also check the acceptance criteria and if any changes appear, we can upgrade safer thanks to them. We can also perform multiple browser checks easily, test the whole app delivery flow and automatically check licensing as well as practices. However, we should remember that tests do not prevent us from every possible failure. They are more like a bulletproof vest - they can help us survive the battle but do not make us immortal.

One more thing…

Finally, I would like to show you something I had been working on for some weeks now, which are Ember testing guides. Together with the team, we managed to prepare some testing guides that cover most of the subjects in the Ember testing world. The guides are a kind of Ember testing cheat sheets and will be updated and extended and from now on, we finally have a place where we can find many testing options.

If you need help with your Ember development, feel free to contact our team of experts.

We have also created a downloadable Ember testing guide that will help you improve your work and provide best practices.

Watch the presentation: