Handling anything at a big scale always is very different from when things are small. The differences can be in the number of people working with something, the business impact of decisions and the ability to enforce the execution of decisions at a large scale. I have in the previous post talked about different tools to automate logic and business rules in Angular apps using eg. TSLint, Prettier, Schematics and CI/CD pipelines. My mantra, that is ever ringing in my head when I work for bigger enterprises is:
“If it can’t be automated, don’t bother”
Christian Lüdemann
I might even create a poster for this at one point so you can have it hanging in your office. Having automatic enforcement of the enterprise’s processes is not the best way to enforce it. IT IS THE ONLY WAY TO ENFORCE IT.
This posts will go in depth with a checklist for handling Angular apps in a scalable way for big enterprises:
1: Automate the WHOLE delivery process
You sure you have heard this a lot of times, Having a fully automated delivery process means that every one can release to production on the team (given they have got an approved pull request). The best teams I have worked with have also used feature sites and automatic end-to-end tests to making the delivery processes even more automatic and safe. For more on this, I recommend reading my blog post on implementing continuous delivery.
2: Automate documentation of code
You might already be aware that you should be documenting: the high-level overview and that the documentation should explain “the why” and not “the how” (reasons behind eg. why some hack is made). The code should be clean and self-explaining enough to not need comments. That being said, doing the necessary documentation should, of course, be automated, otherwise, it will simply not be maintained.
For generating the documentation Compodoc is a great tool to generate a static page that will document your app.
3: Automate code style standards
As I have spoken about in the previous post, having an efficient decision-making process is not enough. Without using tools for enforcing the decided standards, it will simply not be enforced consistently. People tend to underestimate how forgettable the human brain is and how much we like to stick to our ways of doing.
TSLint is the industry standard for enforcing code style standards in Angular apps. It has a lot of rules out of the box and Angular CLI comes with Codelyzer which will enforce the Angular best practices. Should you have specific code standard rules for your business you can enforce these by creating your own TSLint rules.
4: Automate formatting
Formatting is, as well, an area where you don’t want to spend time enforcing it manually in PRs. Prettier is coming to the rescue here and will ensure that the code will look nice and consistent regardless for each check-in. Normally formatting is enforced either with a pre-commit hook or on the CI.
5: Automate code sharing
NPM packages are used by many teams to share code between projects and the same problems are faced every time:
- You need to create a dedicated repo, demo project and CI for each shared lib
- It is tedious to create a change in a shared lib because you need to update the clients
- You face problems with dependency mismatching, eg. Angular 6 in one project and Angular 7 in another
- Npm link, do I need to say more?
These problems will naturally cause the team to share less code and duplicate more, as this becomes the path of least resistance.
A better way to do this is to do the mono repo approach. This is why you will hear about industry-leading companies like Google and Facebook having all their code in one repository. With a mono repo, sharing code is very easy and if you have created something in one app, you want to share with other apps, you simply copy the files to the shared lib.
Of course, these benefits come with a price: you need better tooling to manage the CI/CD pipeline. Nx and Lerna are great tools for managing the mono repo. NX gives you a set of schematics for working with mono repos, such as only building and testing the affected code and Lerna allows you to run tasks on multiple apps and libs in a mono repo. Make sure to stay tuned for next blog post, because I will in this go in depth with how to set up a mono repo and implement the necessary tooling on the CI/CD pipeline.
6: Automate to promote best practices with Schematics
The Angular CLI gives you a lot of tools to generate different kinds of files such as services, components, directives, and tests. These generated files might not fit your companies conventions completely or you might want to extend on them. Angular Schematics allows you to do this so you can control eg. how a test file should look when it is generated. Tomas Trajan has written a good blog post on how to create Schematics. I will soon write a blog post on how to work with schematics in Angular 7 with NX.
Conclusion
This post went through how to automate the enforcement of processes and ways of doing as this is the only real way to get it enforced. Especially as the organization grows this only becomes harder. First is the delivery process that should be automated so every team member, given an approved pull request can ship safely to production. Second, that documentation should be automated as much as possible as manual documentation will rotten over time. Enforcement of code standards and formatting using TSLint and Prettier to ensure that the code looks the same regardless of the developer who has written it. Automate code sharing by using the mono repo approach instead of NPM modules. Lastly, writing custom schematics for your company to customize how generated files should look.
