This document is intended to provide guidelines for the development
processes of the eCommerce platform. The process is designed to be light
weight and efficient while adhering to current industry standards.
Although this document may not capture 100% of the scenarios that may be
encountered throughout the development process, this document is to be
considered a living document that may be updated in the future to
document and unforeseen. The format of this document will focus on the
high level processes initially then explore the details of each process
in sequential order. Any miscellaneous, but relevant processes will be
amended towards the end unless another logic order is more ideal.
Link to Process Diagram:
1
The development lifecycle is modeled after agile product development
practices with a scrum management process. In the figure below, 10 key
high level processes are identified for managing the development
processes of the eCommerce platform starting with platform road mapping.
For each key process, the roles that are involved in that process are
identified in the figure below.
The sales role is filled by either the active Vice President of Sales or
a sales team member tasked with providing input for the direction the
platform from the sales team. The primary function of this role is to
provide feedback in the product development process that will help shape
the platform into the ideal product to sell in the target market. Sales
also follows up with the client currently which will provide feedback
for the improvements on existing features that are needed.
The marketing role is filled by the active executive from the marketing
department. This role is intended to provide insight on the competitive
landscape and the ideal target market to develop feature or to fill
voids in certain market areas.
Firm partners are roles that have equity interest in the firm, such as
the CEO. The partner roles are required for the platform development
process to ensure firm resources are used efficiently and the product
direction is in line with the vision for the firm.
The role of the platform lead is to be the deciding factor in the
technical direction of the platform. This role also manages the key
parts of the development process to ensure quality, consistency, and
technical support or guidance to other development members. This role is
intended to help knock down development roadblocks to help ensure
progress.
Management includes development managers for the front and backend to
ensure adequate resources are allocated to meet timelines.
The project management role is to ensure timelines and expectations are
within reason.
Senior development roles are any developer positions containing senior
titles. These roles are vital in the process to provide key
architectural and technical insights for the products technical
direction. These roles also help in the development the features of the
platform and improve development processes.
Developers provide the technical skill sets to create the product
features.
QA members review the finish development of all features to ensure
product issues do not make it to clients.
The stakeholders are responsible for providing insight and details for
specific tasks. This role could be comprised of either an internal
employee or designated customer.
The road mapping process is designed to identify all features need for a
commercially viable product and prioritize them based off business and
technical needs. This process takes the form of a quarterly meeting
between all roles involved. Prior to the meeting each individual is
required to compose a list of newly identified features and send them to
all participants. Each newly identified feature should contain a short
description of the business needs, a priority, and a description of the
functionality required by each feature. During each meeting the group
reviews, discusses, and approves new features. The group will also
review existing features and decide whether to demote them from the
roadmap. Once the list is approved each road mapping iteration the top
priority features will be grouped in to 2 or 3 sequential releases in
which the releases will be developed.
A release cycle is the development process to complete a group of
features from the roadmap that has already been defined for the release
by the road mapping committee. Each release starts off with reviewing
the individual features assigned to the release and then defined into
tasks with functional and technical details in VSO, the release
management tool. Once all features of the release have been broken into
concise and manageable tasks, the task are then organized into two or
more sprints, about two weeks long each, which make up the release.
Based on the amount of effort and resources available a timeline will be
determined for the series of sprints to be completed by to calculate a
release date. After the sprints and timeline are solidified a sprint
cycle may begin.
The sprint cycle is the actual development process of the tasks assigned
to a sprint. The cycle starts off with a planning meeting to finalize
the details of the sprint then moves into a setup of the sprint and
feature development. After each feature has been developed, a QA member
or stakeholder will review the wok completed to make sure it
functionally satisfies the business needs. Once the business needs have
been met for a feature, the code developed is reviewed by peers to
ensure quality and best practices. When all the features have been
completed, the new features developed in the sprint will be reviewed one
more time prior to updating the release branch with the latest. After
the sprint development has been completed, a sprint retrospect is
performed to assess what worked well, what didn't work well, and what
needs to change for the next sprint.
During the sprint planning tasks are reviewed to make sure the timeline
is realistic. Any adjustments to the sprint are made at this time. The
only exceptions to adjusting the items being worked on in a sprint are
if urgent business needs have been submitted to crash the development
schedule or sprint items have been completed ahead of time. When
reviewing the sprint items, there are several things that need to be
reviewed or provided. Below is a validation list for the sprint items in
VSO.
After all items have been reviewed and pass the criteria, the time
required to develop each item of the sprint and available resources
should be reviewed to verify enough resources have been allocated to the
sprint. When all the details have been solidified and risks have been
identified then the sprint may begin.
The sprint set up is composed of a few tasks that need to be performed
prior to each sprint. Below is a list that details the tasks need prior
to starting a sprint.
During the QA process, a QA member or stakeholder will review the newly
completed feature and verify that the expected functionality is working
correctly. Ideally a separate environment is set up for this review for
the QA member or stakeholder to review the feature. During this time,
adjustments may be needed in order for the feature to be acceptable for
a completed status.
When the Task has been marked for completion, the developer of the
feature will need to send an email to one or more peers detailing the
change and files. If the peer, approves of the implementation then the
code can be merged into the sprint. If the peer does not approve, then
the peer needs to detail a more ideal implementation or note any
adjustments. Once the code has been deemed to be in good standing then
it can be merged back into the release branch.
After all tasks have been completed or the sprint timeline has finish,
then a sprint retrospect needs to be completed. This can take the form
of a meeting or an email, but the following items need to be detailed
out by the team prior to starting another sprint cycle.
(Video) Development & QA Cycles During a
Project
A Code Review is an action taken by a senior team member to review code
commits submitted by other team members, looking to ensure that all code
in the commit meets the Coding Standards. The purpose of a Code Review
is to ensure that no new code is accepted which would go against the
patterns, naming conventions and aesthetics of how we want the solution
code to appear. If a particular code commit does not meet certain
expectations, the commit can be pushed back to the developer with notes
to make specific corrections.
Code Reviews play a significant part of the Gated Checkin process, where
the code actually can't be pushed to the main branch without an approver
signing off on the code.
CI process should handle the first part of a Code Review, checking that
the Unit Tests cover the new code and that all Unit Tests pass. If a
unit test fails, the Commit should be automatically kicked back to the
user.
Additional points we can add to the CI process include running StyleCop,
FxCop and ReSharper analysis with Rule-Sets to check for changes and
provide a detailed report to the user if any rule should fail.
The last part should include the senior team member either directly
reviewing the new code if it is a simple change or sitting with the
developer for more complex changes. In the code review, the reviewer
should be checking the code for things that don't coincide with the
overall plan of the platform and/or the clients that it is intended for.
NOTE: We will be adding the step-by-step instructions for doing this in
TortoiseGit, VS and VSO once the Gated Checkin process is finalized.
Until this time, you may review any and all code commits for any version
via the CEF branch pages in Stash:
http://stash:7990/projects/CEF/repos/framework/commits?until=refs%2Fheads%2FRelease4_1
(Video) What A Good QA Testing Plan Should
Include
The below guide will help team members with the eCommerce Website QA
process
Recommended areas to confirm eCommerce Site functionality:
Use the bug reporting standards to issue bug reports using the tools for
that particular project
Note that typically the more information provided the better someone can
debug quickly
Key items are browser version, dimensions, page url, IP and date/time,
highlight of the screen / screenshot, and notes
Typically if there is an issue with the platform it will show within the
console log of the inspection tool. If you can identify the request and
response detail it will typically help the development team resolve the
issue quickly if it's a simpler error for them. Note that you can use
Firefox, Chrome or other inspector tools to get the same information.
Cloning is really the default behavior you'd expect from SVN. This is
how you'll create your local working copy. You don't need permission via
pull request to merge back (assuming you have r+w to the parent
repository). You should clone a repository if you plan to push your
changes back to the same repository where you have read+write access
privileges. You should also clone a repository if you are building a new
repository that is unique.
If you want to contribute code enhancements to an existing repository,
you should create a new repository by creating a fork of the original.
For example, if you want to contribute minor bug fixes, enhancements, or
new features to another git project, the easiest way for those changes
to be merged into the original repository is with a Pull Request from a
forked repository. See Make a Pull Request on GitHub.
Note: When you fork a repository, all metadata associated with the
repository such as commit messages, branches, tags, etc. are copied over
to the new repository so that it's an exhaustive duplicate of the
repository and all of its contents.
Use these links to get basic overviews:
This How To will explain how to use GIT and Stash at Clarity
Login access to the Clarity network and access to http://stash:7990 or
via http://www.claritygit.com:7990 (note you can create a host entry
for stash = 10.10.30.90 if your DNS isn't resolving).
git commit --amend -m "New commit message"
Any time you would hit the save button. Really, you can't have too many
of these
Don't worry about dates. Git takes care of that for us, but do tell us
what you're doing short and sweet... but not too short.
implementing javascript fixes on MegaMenu mobile toggles'
"I did stuff to make things happen"
"It little profits that an idle king, By this still hearth, among these
barren crags, Match'd with an aged wife, I mete and dole Unequal laws
unto a savage race, That hoard, and sleep, and feed, and know not me. I
cannot rest from travel: I will drink Life to the lees: All times I have
enjoy'd Greatly, have suffer'd greatly, both with those That loved me,
and alone, on shore, and when Thro' scudding drifts the rainy Hyades
Vext the dim sea: I am become a name; For always roaming with a hungry
heart Much have I seen and known; cities of men And manners, climates,
councils, governments, Myself not least, but honour'd of them all; And
drunk delight of battle with my peers, Far on the ringing plains of
windy Troy. I am a part of all that I have met; Yet all experience is an
arch wherethro' Gleams that untravell'd world whose margin fades For
ever and forever when I move. How dull it is to pause, to make an end,
To rust unburnish'd, not to shine in use! As tho' to breathe were life!
Life piled on life Were all too little, and of one to me Little remains:
but every hour is saved From that eternal silence, something more, A
bringer of new things; and vile it were For some three suns to store and
hoard myself, And this gray spirit yearning in desire To follow
knowledge like a sinking star, Beyond the utmost bound of human thought.
This is my son, mine own Telemachus, To whom I leave the sceptre and the
isle,— Well-loved of me, discerning to fulfil This labour, by slow
prudence to make mild A rugged people, and thro' soft degrees Subdue
them to the useful and the good. Most blameless is he, centred in the
sphere Of common duties, decent not to fail In offices of tenderness,
and pay Meet adoration to my household gods, When I am gone. He works
his work, I mine. There lies the port; the vessel puffs her sail: There
gloom the dark, broad seas. My mariners, Souls that have toil'd, and
wrought, and thought with me— That ever with a frolic welcome took The
thunder and the sunshine, and opposed Free hearts, free foreheads—you
and I are old; Old age hath yet his honour and his toil; Death closes
all: but something ere the end, Some work of noble note, may yet be
done, Not unbecoming men that strove with Gods. The lights begin to
twinkle from the rocks: The long day wanes: the slow moon climbs: the
deep Moans round with many voices. Come, my friends, 'T is not too late
to seek a newer world. Push off, and sitting well in order smite The
sounding furrows; for my purpose holds To sail beyond the sunset, and
the baths Of all the western stars, until I die. It may be that the
gulfs will wash us down: It may be we shall touch the Happy Isles, And
see the great Achilles, whom we knew. Tho' much is taken, much abides;
and tho' We are not now that strength which in old days Moved earth and
heaven, that which we are, we are; One equal temper of heroic hearts,
Made weak by time and fate, but strong in will To strive, to seek, to
find, and not to yield."
Don't be like Ulysses. It sucks to be Ulysses.
Pushing code should only happen when it is complete and ready to go to
live. This means you have tested it on your system and it works as
expected.
When you're just wanting to save your work or someone wants to see it.
Commits are for saving and deadlines are for show (this part may be
argued, but legit serious about the commit part).
When 2 developers work on the same file, probably for different reasons,
sometimes to fix the same bug, eventually both persons will try to
commit that file's changes. The first person which gets it in will
succeed normally, and the second will be forced to pull the other commit
down and Resolve a Conflict. Various tools exist which can allow
conflict resolution.
In most cases, if the two developers didn't alter the same set of lines
(dev A could have edited the top part while dev B did the bottom part),
then the conflict will basically resolve itself. You may even not have
to use the Conflict Merge tool in some of those cases. However, when 2
people have worked on the same part of the same file in different ways,
it must be manually merged. This is called Resolving a Conflict.
You can see in the image above a common conflict merge tool and the
views it displays:
From here, make your commit normally and push it to the server.
Please see the attached document for the original excel file and
the PDF for the exported view.
If you want to create your own sub-branches, you are welcome to do so.
This is usually done if you're working on multiple features/functions
and you want to have the ability to push one at a time to the current
Dev-Master. It helps eliminate merge conflicts.
So everyone can break their own stuff. It's like the lock that keeps
your sister's out of your room so they can't break your toys.
The current version of CEF is 4.7.0, please use the 4.7.0/Dev-Master
branch as your go-to branch to start any development work as of
12/05/2016.
Sometimes when coding you need to make a change that will affect how
other developers need to pull this change into their environments beyond
the standard pull-merge-continue method. When this happens, clear
documentation must be included on what actions must be taken to perform
the upgrade at the time of pull-down and steps must be taken to share
this information with the team.
Steven makes a commit that includes a new EF Code-First Database
Migration because he added a column to the table schema for Products.
His local copy of the database has already been upgraded to the new
schema but no other copy of the database, such as the Staging
environment or Emily's local copy has been updated. When Stephen makes
his commit, he needs to add the following to his Commit Notes:
*Upgrade Required!*
1. Open solution VS
2. Compile the solution
3. Set the DataModel project as the Project Startup Application
4. Open the Package Manager Console from the View menu
5. Enter Update-Database -Target XXXXX
6. The database update should run and succeed. For issues, please see Steven
You can see above that he's informing developers exactly what needs to
be done and we have a permanent record to review that.
The following videos are relevant to this subject:
The following key factors should be considered when prioritizing or
ranking bug fixes.
A bug report that meets any of the following criteria should typically
be treated with urgency:
How long a bug fix is expected to take should be considered along with
other factors. For example, a bug fix that meets the criteria for urgent
intervention and that can be resolved very quickly should almost always
be near the very top of the list. Alternately, an issue that is not
particularly urgent and that will furthermore take a long time to
address should be near the bottom of any list.
Most of these can be readily inferred from the urgent list.
Please use this process below to document any bugs with the CEF
platform.
In Scrum, the sprint planning meeting is attended by the product owner,
ScrumMaster and the entire Scrum team. Outside stakeholders may attend
by invitation of the team, although this is rare in most companies.
During the sprint planning meeting, the product owner describes the
highest priority features to the team. The team asks enough questions
that they can turn a high-level user story of the product backlog into
the more detailed tasks of the sprint backlog.
The product owner doesn't have to describe every item being tracked on
the product backlog. A good guideline is for the product owner to come
to the sprint planning meeting prepared to talk about two sprint's worth
of product backlog items. To make an example really simple, suppose a
team always finishes five product backlog items. Their product owner
should enter the meeting prepared to talk about the top 10 priorities.
There are two defined artifacts that result from a sprint planning
meeting:
The sprint backlog is the other output of sprint planning. A sprint
backlog is a list of the product backlog items the team commits to
delivering plus the list of tasks necessary to delivering those product
backlog items. Each task on the sprint backlog is also usually
estimated.
An important point to reiterate here is that it's the team that selects
how much work they can do in the coming sprint. The product owner does
not get to say, "We have four sprints left so you need to do one-fourth
of everything I need." We can hope the team does that much (or more),
but it's up to the team to determine how much they can do in the sprint.
CREDIT FOR CONTENT ABOVE:
8
A Software Change Notice (SCN), or change notice, is a document which
records or authorizes a change to a specific design. The reasons for the
change should also be recorded.
Following sound engineering principles, control and documentation are
necessary to ensure that changes are built upon a known foundation and
approved by relevant authorities.
"[A] document approved by the design activity that describes and
authorizes the implementation of an engineering change to the product
and its approved configuration documentation".
An SCN must contain at least this information:
Changes are considered report-able when they affect the performance or
life span of a product. Such changes include any that affect the form,
fit, function, or the product technical specification (i.e.,
documentation) of the product. The desire for supplier or customer
trace-ability may result in a report-able change.
Note: The following is just an example and not part of a real change
notification
Product schema now stores kit information and relationship with a Kit
Parent Product
To support Product Kits as designed by Microsoft Dynamics GP's ERP
system which Clarity Connect supports pulling product and kit
information from, some changes needed to occur in the CEF schema and
workflows.
Three data points have been added to the Product table:
The store should display the Kit item with specialized UI for stating
that child items are part of the Kit. Only the Kit item should be added
to the cart as the ERP system will assign the quantities of the kit
parts for distribution after sale.
This schema and workflows change requires a Database update which must
be issued via EntityFramework Code First Update-Database method, state a
Target of GPAdjustments02 to specifically implement these changes.
