Beberapa points yang menarik:
- Python merupakan bahasa yang di pahami oleh semua Mozilla Web Developers
- Kebanyakan website di bawah naungan http://mozilla.org menggunakan Django Framework
- Website utama Mozilla sedang dibangun ulang menggunakan Bedrock (https://github.com/mozilla/bedrock) yang berbasis Python
- http://support.mozilla.org (https://github.com/mozilla/kitsune)
- http://addons.mozilla.org (https://github.com/mozilla/zamboni)
- http://input.mozilla.org (https://github.com/mozilla/input.mozilla.org)
Dalam hal testing, salah satu Web Developers Mozilla menuliskan:
Salah satu utility untuk testing Mozilla.org adalah sebuah project yang bernaung di: https://github.com/jbalogh/test-utils. Mereka juga menggunakan nose testing framework (http://readthedocs.org/docs/nose/en/latest/)Testing - To add to what Fred said, we also use jstestnet (kumar303 wrote it) to include our QUnit(JavaScript/front-end unit tests) in our CI results. Our WebQA and Automation teams are big contributors to and consumers of the Selenium test automation project. We're working to get those tests included with the nose/QUnit results, because a failure is a failure is a failure, no matter where it failed.We also have developed a culture of testing--this is something I've been meaning to write a blog post about. That means a few things:
- Time to write tests is included in how long it takes to write the code under test. A feature isn't complete without tests.
- If you break the tests, there's some good-natured teasing, and you lose points in the CI game. Light social pressure is incredibly helpful.
- If you break the tests, your first priority is fixing them.
Next I want to develop a culture of performance.Deployment - This is my favorite topic! I've been giving talks on it for around a year now. I actually started putting a joke about that into my talks about it.My goal with all the projects I touch is to deploy continuously. Not only does continuous deployment mean fixes get to users as fast as possible, but it has a bunch of requirements that are great in-and-of themselves, like...
- You must have a robust, automated, and fast deployment pipeline. One-button and wait.
- You must have a high confidence level from automated tests so you don't break things.
- You must have active, real-time monitoring of the site.
- You must keep master/trunk/whatever branch in a clean, working state, all the time.
- Developers must develop a sense of ownership over their code that lasts all the way out the door.
It also has a number of side benefits, like not doing code pushes at night when people are tired, or about to leave for the day.Some projects are closer than others. We learned a lot from Etsy (link to blog post and video, watch Kellan and Erik's sections). But their Deployinator tool is Ruby, and it took them a while to open source it, so we built Chief to do the same thing (run some shell scripts, print a bunch of output).We've got push-button production deploys with Chief or other, ad-hoc tools, for a few sites now. We've got it set up in the -stage environment Fred mentioned for a few more. We use another tool called Freddo to deploy -dev environments on Github post-push hooks. My goal is to have all new environments set up with Freddo and Chief by default in the future.
Beberapa angka yang cukup menarik perhatian:
- Mozilla memiliki lebih dari 100 websites
- Traffic: 1000+ pengunjung/day - 100juta+ pengunjung/month
- API: Milyard-an API calls
- Localized dan juga tersedia translasi untuk 30+ bahasa
Tidak ada komentar:
Posting Komentar