Team Size

Developers are put into integrated teams of no more than 12 self-sustaining members, and test infrastructure changes such as code changes. Ideal size of a development team is:

• One Tech lead - often mature senior engineer, or CTO

• Two to four Senior Full Stack Developers - again, those with ample experience

• One Designer - Not many that fit this bill. Designer must be able to do UI/ UX and front end code.

• One Scrum Master / Product Owner - This is a non development professional who works with the Tech Lead to manage the work, set the vision, document requirements, and gather feedback.

Development Environments

In software, web and mobile application development, the development environment is a workspace with a set of processes and programming tools used to develop the source code for an application or software product. Development environments enable developers to create and innovate without breaking something in a live environment.

Assied from the technical underpinnings of a development environment, we find it it not only necessary but also extremely helpful to have the following environments:

• Local - A local development environment (LDE) is a way of configuring services on our laptop/desktop to run a website or a web application. Local development has nothing to do with your physical location. It isn’t about using locally sourced software, a coworking space, or supporting your neighborhood coffee shop by drinking your fourth cup while working away on a client site (though I won’t fault you for that).

  This entails installing a web server, a database, and some sort of a language as Node. js, Python, PHP, and others.

• Master - The development server is used to test the code and conduct application performance checks. Once successfully tested, the developer moves the application to the staging server.

• Demo - The demonstration “demo” environment will allow Strike Labs to showcase features and functionalities without impacting the production environment. The demo environment will be used for users to educate, test, and promote the Atmospherics platform.

• Staging - The staging server looks exactly like the production server environment. Using a staging server enables developers to run tests on the staging server to ensure reliability and avert failure in an actual production server. Running tests on the staging server is usually the final step before deploying the application to a production server.

• Sandbox - The “sandbox” environment will be a dedicated environment for users and clients to build, test, and experiment with the platform. The Sandbox and Demo environments do not impact the production environment and are quickly and easily reformatted for repeated use. A sandbox is a testing environment that isolates untested code changes and outright experimentation from the production environment or repository, in the context of software development including Web development, Automation and revision control.

• All developers commit code to the main trunk (a.k.a. “Master”) frequently and ensure there are no long-running feature branches.

• Production - A production server or live server is used to host website content and applications for deployment to a live environment. Once the application is approved, it becomes part of the production server.

Test Driven Design & Automatic Testing

Developers build unit tests toward 100% coverage of the code base, ensuring that unit tests cover 95% of the overall code base. The team conducts audits to ensure that unit tests are up-to-date. Unit test failures should be fixed, not bypassed.

Continuous Delivery Configuration

The team handles continuous delivery configuration as if it was code, establishing role-based security controls. The team lead monitors and tracks every resource for productivity.  Metrics such as the number of builds, number of deployments, the average time for changes to reach production, the average time from the first pipeline stage to each stage, the number of changes reaching production, and the average build time are captured and analyzed to identify areas for improvement.

Push to Production

Strike Labs pushes code releases to production whenever there is an improvement and after the proper testing is completed. Production pushes occur multiple times a day,  no matter the size of the update or change. This methodology allows Strike Labs to implement dozens of changes a day. The team believes that if an improvement, update or fix has been tested and in the queue, it should not be held for release. For example, an improvement that has been tested and in the Master branch for more than two (2) days is too long.

Software Development Life Cycle

The Software Development Life Cycle “SDLC” memorializes our practices and processes in a well-documented and transparent manner. It answers the question: “How do we develop software here?”

• Process - How does work go from idea to production? How do we define requirements & acceptance criteria? How do we do Quality Assurance and User Acceptance Testing? What does “done” mean to us?

• Coding Standards - consistency to ensure maintainability & transferable skills

• Documentation Standards - which changes require documentation? How do we maintain that documentation? Documentation covers architecture, infrastructure, code, and domain knowledge

• Testing Strategy - Develop and implement automated testing strategy, code coverage targets, document our manual QA test cases

• Code Reviews - every change requires a code review, non-negotiable. Developers hold one another accountable for adhering to code, documentation, test standards, etc.

• Branching Strategy - Adopt standard practices so all developers understand work in progress (example)

• Deployment Strategy - Well documented deployment model with clear guidance on how to deploy new code, including data migrations, compiled frontends to content delivery network, etc., and how to roll back

• Operational Runbooks - Clear technical documentation for common or expected technical issues so team members can execute quickly and without ambiguity in urgent scenarios (Example: what to do if the database is offline)