In this article I’m gonna describe you – How to Set Up StartUp Basic Architecture – in a little bit more details – easily understood by technical person than standard non-it manager.
Ways of software development – Methodology
The delivery coordination between the team members – in majority of cases – will be Agile or Scrum or some process similar to them. In either cases – the goal is to have build fast, move the features from developer’s hands to the testers device or environments.
Use Linux Containers (example Docker)
Throw to the garbage bin the case where “It Works on My Machine”. Using containers, you could run most* tasks in an identical environment (minimal Linux with app specific packages added). There are certain tasks that will require different Desktop OS, but in general, it shouldn’t matter on platform you are developing.
- Building things for the Apple Platforms will require for you to have MacOS host machine. You may try to run Hackintosh, but I doubt you want an environment that may stop working after an update where – Apple has fixed the hacks in the OS.
- There may be certain services or apps that may require Windows Desktop. It’s a little bit easier to do that. I’ve tried a Virtual Machine offered by Microsoft at one point – for one time tasks – with limited in time (sandboxed) Windows.
- For Linux Dependencies on Windows – there is a Subsystem developed by Microsoft.
Have a Git Setup
Git is the winner of the Source Control Management Systems. It is a creation of Linus Torvalds – the creator of linux. It is open source. If you’d like – you could run it on your own machines and there are several cloud service providers, that enhance it with all the building, packaging , delivery, integrations and even hosting.
You should have Local and Remote Repositories. Local is to keep track of your changes. Remote is for Integration with other team members and all the other functionalities
Continuous Integration
You’ve got to elevate the importance of local tests. Having functionalities that are tested – even before they leave the developer’s machine is essential for quality. Tests could be executed before git commit or before pushing the changes to the remote repository.
Hard part comes, if you have functionalities that require some things to happen in other modules. This is integration testing. For real testing – there should be no mock responses from external Micro Service. What is needed is – the test to run multiple applications in test mode – where – maybe the database could be mocked in all micro services. But all the actual logic in the code should be executed.
Continuous Delivery
There should be a script that compiles, builds, packages, signs and does whatever needed – to deliver versions automatically. In perfect multi-corporation setup there are 4-5 environments. Delivery to all of them should be automatic, but, the delivery to production in general – should not happen from the chain of jobs executed after pushing code changes, but from minimal manual step – after logic verification from a tester.
Publishing Process
If you are publishing mobile applications there is a Continuous delivery software called fastlane. It executes the deployments to the big app stores.
There are similar packages for
- Deploy to Clouds
- Manual Upload to Private Cloud
There are tricky moments for compiled programming platforms where:
- the Backend Services should Stop
- get updated
- then Started
For 100% up-time of your setup you should put a Load Balancer on the front-side. This will allow starting two (or more) instances of the same app or micro service – that will handle big loads and will also benefit the update process. One by one the micro modules could be stopped – updated – then started – while still having the old instance running.
Goal – to have as automatic as possible delivery of new versions
I’ve coded simplistic open source packages that handle update:
Prepare at least draft of the release notes
Some initial version of the release notes may be compiled from the Git Commits. They most likely will have developer or internal information that should not be made public, but they could be the basic point from where to form user/business friendly changes in the release.
This article represents one of the steps of s start-up. I’ve written a small booklet with several other steps. You could check it out at https://programtom.com/dev/product/the-start-up-ultimate-xx-steps-pdf/
Images from https://pixabay.com/