Pragma On Key Silverlight Localization

One of the big features that we are adding to Version 5.4 of On Key, Pragma’s Enterprise Asset Management System, is the ability to use the system in different languages.  It seems like the first language we will support in addition to English will be Brazilian Portuguese  to support customers for our Pragma Brazil service company.  So I’ve been spending some time during the past week or two looking at the various aspects of On Key that we need to localize to determine the best solutions for getting everything localized.  In this post I will cover some useful information I discovered in my research.

Pragma Software Development: Check-in Procedure

When working together in a software development team it is important to have a common definition for when something is DONE.  An important aspect of getting things DONE is a well-defined check-in procedure that all developers follow to commit something into the source control repository.  Here is the procedure that we use at Pragma for committing changes into our Team Foundation Source Control repository:

1. Code has been integrated with a recent version of the code in the TFS repository – at least a version of the TFS repository on the same day.
2. Code has been formatted according to our ReSharper Pragma Full Cleanup profile.  This automatically formats all code to follow the same formatting and layout standards.
3. Code compiles without any compiler warnings.
4. Code adheres to our coding standards - I’ll write more about this in a future post.  We try to automate the application of our coding standards (where possible) using tools like ReSharper.  Alternatively, use a code review checklist to quickly identify areas of concern. 
5. No ReSharper code analysis Error or Warning violations (i.e. green square in scrollbar). Any violation needs to be identified and agreed upon. Suggestions and Hints can be ignored if deemed unnecessary.
6. No FxCop violations. Any violation needs to be identified, agreed upon and justified using the in-code SuppressMessage attribute.
7. New functionality has been covered by tests and the code coverage has been verified using NCover.
8. Bugs have been covered by tests and verified using NCover.
9. Code adherers to the Logging strategy and the developer has inspected the usefulness of the log statements using Log4View.
10. Code adheres to the Exception handling strategy for managing exceptions.
11. Error Messages and translations have been added to the resource files.
12. The associated TFS work item (development ticket/task) has been updated to reflect the effort involved (actual hours, comments etc.)

Once the code satisfies the above mentioned criteria, the developer runs a gated check-in using the TeamCity Visual Studio Plug-in.  This ensures that all the unit and integration tests are executed by the TeamCity build server after integrating the local changes with the latest TFS repository changeset.  Only if all the tests pass will TeamCity commit the changes onto the Mainline.   The observant reader may have noticed that we don’t do an upfront code review.  As we work from home for 2-3 days a week, we conduct our code reviews on the checked-in artefacts.  I’ll write more about the code review procedure in a future blog posting. 

Lastly, for service pack development, the developer needs to consider whether the change needs to be merged across to the Mainline for the next major version and merge the changes across if required.