- Episode 1 – Introduction
- Episode 2 – Backend / Infrastructure
- Episode 3 – Frontend Setup
- Episode 4 – Data flow
- Episode 5 – Tests / Security
- Episode 6 – It’s your turn (you are here)
- Episode 7 – migrate from ASP.NET Core 1.1 to 2.0
Nice journey behind us! You did really great job to be here with us in episode 6.
We started this course with introduction where we tried to explain goal, rules and technology stack. Next we did core architecture of our application, few first features and we showed you basic concepts of security and automatic testing. Thanks to those steps now we have prepared some kind of framework.
You can think -What framework? Next framework?
We’re using various frameworks and libraries in this project. On top of that we created our framework which gives you an idea how you should build components on frontend, work with data access on backend, how to return errors etc. We can think of this like some kind of guidelines. When next developer will join this project he should follow those rules. This is how it looks like in real-world projects.
Ok, but let’s go back to our course. Right now you should be able to do at least few next features basing on those rules. This is why we decided not to do those features for you, but to challenge you. Before we’ll show you what is your task let’s sum up few things.
Currently our application can be described as development-ready. It means that basic configuration of various parts of it is done – back-end part is layered, basic front-end structure is prepared, and data flows back and forth. Our goal has been achieved – we know how to create basic ASP.NET Core application with React-based components.
Does it mean that we’re ready to deploy our application to production? Not yet. To achieve that, we would have to make some additional improvements:
- data validation
Data needs to be validated on various layers. Database should have applied it’s own integrity rules, and when it comes to application part, various data validators should be prepared for both back-end and front-end parts.
- production-ready front-end
Currently our front-end is prepared only for smooth development experience. Before deploying our code to production scripts should be optimized and minified with i.e. Webpack plugins.
- higher tests coverage
To be sure that we can maintain our application for a long time, we would need to create more tests of different type.
- logging policy
What’s the status of our application after deployment? How could we check if there are no runtime errors? Of course we would need to create logging policy to log and monitor various types of events, errors and informations from it.
- build scripts
Manual build process currently takes a lot of our time. We need to build our back-end, we need to use Webpack to build front-end, and also database migrations are applied manually. In real-life all of that should be executed from unified build scripts to be sure that everyone follows the same path.
- automatization of deployment
We can automate our work by introducing concepts like continuous deployment to get rid of manual deployment process. After each push to repository build server would be able to pull new changes and based on them new version of application could be deployed to selected environments.
- multiple environments
Speaking of environments – one is definitely not enough. There should be at least one for developers (like sandbox, to create and break new things, it’s often called dev), another for testing purposes and verification of new versions (called staging or integration) and the last one for our users (production, where only tested and stable versions should be deployed). Different companies are using different names for all of them, but in general idea is the same.
So why we didn’t we prepare description for all of these points? Because there are books about preparing production-ready applications! This topic is so big and so team-dependent, that we can’t describe everything and just say that ‘you should do this and that and everything will work well’. You will see how deployment works during work on real life projects – that’s the best way to learn something more about it!
Like in real-world projects and developer everyday work
Though we described our application as development-ready it doesn’t mean that result of this course is just next “tutorial” application. We built it like we would do it in normal project. You need to be aware of things which are still to do to be able to describe this app as production-ready, but you also must know that most of projects start like we did it in this course. That means you gained nice amount of experience!
Of course as application will grow architecture will need to grow also. Maybe additional layer would be needed, more extended components on frontend etc. It’s possible even that if this kind of application will grow too big, we can decide to devide it to two or few smaller applications and eventually gain microservices architecture. As we said this topic is very, very big and it requires a lot of time and whole team of developers, not just one person. Right now focus on basic concepts and skills which will give you possibility to build apps from small projects to big one step by step.
Be proud of what you did with us here!
It’s your turn!
Goal of this course is to create application for your software house. Environment, architecture and data flow is preapred, but we don’t have a lof of features. Our app is “poor”. It’s good a moment to practise which means that you have to start doing things on your own.
But don’t worry! We’ll not leave you alone. You can write to us on firstname.lastname@example.org if you have some problem or question. Feel free to ask any questions!
We recommend you that first you should prepare short plan of features you want to do. Next get each feature one by one from your list and do it. Use documentation and materials available on the Internet – that’s how it looks like in everyday work! You will have to solve hundred of problems and for most of them you will find solution on the Internet. Welcome in world of software development!
After each feature you’ve done you can write to us, send link to your GitHub repository, describe shortly changes you’ve made and we’ll do code review for you! You will have sure that what you’re doing – you’re doing it right.
If you don’t have an idea what you can do next we have for you sample backlog (list of things which are to do):
- project edit (user should be able to edit project data)
- project status (user should be able to provide project status e.g. todo/in progress/done)
- project budget (user should be able to provide info about how many hours he is planning to spend on specific project, also user should be able to report hours he already spent on project)
- project progress (user should be able to provide info about project progress in %, also user should be able to sort projects list by progress)
- project deadline (user should be able to provide projet deadline, also user should be able to sort projects list by deadline)
- projects search (user should be able to search projects on projects list by project name or project description)
- user accounts and roles (you should provide account for system administrator which can add clients accounts. Clients can look only on their projects in read-only mode)
- project timeline (system administrator and clients can write messages on specific project timeline sth like mini-chat)
Let’s get to work! We’re waiting for your feedback! 🙂