prepare for seminar 1

[tuvelofstrom]

See the instructions in Canvas for seminar 1. Note that the instructions have been updated.

I could not assign more than one of you as assignees. You could change that in your settings. You are all supposed to be assignees of this issue

[Lukasydkvist]

The literature is, in my opinion, more focused on how to work in larger project. But it also have some helpful tips that is applicable for small project as well.

For instance, the book cover a large part of version control which I consider crucial in any kind of project, both large and small. We have been following the books recommendations considering version control somewhat. For example, we all have our own branches that we work with. Its easy for us to reach previous states of the files. We can also see what changes were made and by whom in every commit.

We have also kept in mind that it is safer to commit changes more frequent so that it is easier to track bugs if that occurs. We are also aware of merging with main now and then, so that the branches don’t work on different environments. When it comes to CI, we have created tests and build for our project which is usable. From what I have read, there is much more that we can add to our CI so maybe we will see that further on. Our tests are fast and simple. However we need to add more tests to cover a bigger field of our project. I, for instance, have not added tests for the main menu which I am working on. This is important if we want a good code coverage.

In case of working priorities, we are focused on fixing bugs if they show up. If I am not mistaken, the book brought up on making small frequent commits, and if a bug appear its important to fix that before moving on with anything else. For example, when we were creating our builder, a lot of bugs appeared and before we did anything else we tried hard to fix those bugs. We also try to be as informative as possible in our commit comments. Since we are a small team with good connection, this is not really as important, but it’s a good practise.

Chapter 1 – You are better of committing frequent and small changes, rather then committing less often with bigger changes. Chapter 2 – It is important to have good source code management so that you can go back to previous revisions. Chapter 3 – That CI is about having the entire application built and tested before committing a change. And if there is a build fail, you fix that before moving on with the project. Chapter 4 – That there are different types of tests. Some are more focused on support programming, some on critique project, and some that are more focused on technology facing. Chapter 14 – CVS enables developers to work on the same repository.

[Stocken99]

Preparation for seminar 1.

The instruction does not force me to be formal so i shall not be that!

I think that the main takeaways from the book is to focus to always have a working / deployable product. To my judgement i do believe that we have succeded in this.

There was however some teething problems in the beginning however after we started getting used to the Unity environment the gearing turned a lot smoother.

In my opinion there is not a lot of different techniques we could have used better if we would have the experience that we do have now.

We had for example already used branching, merging and pull request from the beginning. We could however use one branch per feature or issue as the book recommends. (We have done this for some bigger changes) Now we mainly just use our personal branches, do our stuff there then push to remote and merging with main. In my opinion i believe that we have mostly been doing the smaller commits often. Also size is a relatively loose concept. The earth is small compared to the sun and the sun is small relative to Sagitarrius A*. I also think our commit messages are of adequate quality. The names on the issues/commits where in the beginning horrendous. Either to short or to descriptive. This has now changed to the better.

The book mentions this in a section on page 39 about how it can look if you use "obscure commit messages". Total chaos and countless of probably very expensive hours are wasted away because of this. If you read between the lines you can imagine how catastrophic this example would be if the big brained engineers at google left these obscure messages... People would have to use bing for an unspecified amount of time! Practically a crime against professionalism!

We have just implemented Continuous Integration so i cannot write anything about my experience with using this technique. I can however see that there are benefits of using this. It is nice to see if the branch you are pulling from on github are functional.

So instead of: Testing on your local computer, pushing, creating a pull request, merging, then pull the main branch to test if it are functional. Because maybe.... Someone has changed something in the readme file and the whole project is now broken.

You can now skip the local testing of the merged branch and just see so that everything works directly in gitHub. This is in my opinion more of a “quality of life” feature for us. But in bigger teams and organizations this can be very benificial and save countless of time. The book is essential about time saving. It does however mention reducing stress in chapter one which is very good for both the company and the individual worker.

My takeaway continuous integration is that the more people you have on you project the more time you will save. Which mean lesser cost of development which can for example lead to a cheaper product or more features. These are both two points which customers loves!

And as we all can understand : A happy customer is customer coming back! Which essentially means that we can continue our mutual beneficial cooperation to improve the customer satisfaction and fill our coffers! But i am digressing. However you cant let your mind become a prisoner of the litterature. You also need to look at the bigger picture!

We do not have a lot of tests. But then again we do not have a lot of features for now. I do however believe that the tests that we have are holding a high standard. The only feature that do not have tests for now is the menu. But Lukas is working tirelessly on this! (The points are however our priority and these take time) The book mentions that if your tests are supbar a lot of side effects do appear because of this. For example stress (which is a killer), low customer satisfaction (which is no bueno) etc, etc.

Chapter “Oneliners”:

Chapter 1

Commit less more often!

Chapter 2

The aim of the second chapter of the book is to examine how teams can work productively with version control.

Chapter 3

Always test before commiting, also never leave with a broken build (fix the errors as soon as possible).

Chapter 4

Create a strict plan for testing and if any test fails, fix these asap.

Chapter 14

Getting moore people to work on the same project as painless as possible.

[matildaronder]

After I have read the chapters in the book I have got a more width on how important it is to have a good structure in the project and that it is even more important if you are working in a large group.

To begin with, if you are looking at the frontpage of our repostitory, I think we have a good readme file with important instructions on how to run our program and also which requirements is needed. Both for us but also for people who want to test our project. That is super important if you are working in a large group of people.

I think that we have a good communication in our group and that we inform each other what we are working on and if we are going to change anything big. That will help all of us and it will reduce the risk that something will disapear. We have created our own branches and are working on them. That is nice because you don’t get interrupted by the others and hopefully you will not get any big conflicts. If you do any changes, it is important that you write a good commit of what has been changed. But before, always remember to test the code with the unity test so everything is correct and works fine. At the moment, we do not have so many tests but I still think that they are quite good. It is essential that the tests is quite fast, otherwise, you’re not going to do them because you don’t have time to wait. If you get a bug in your code, fix it asap before they get big and can’t be fixed. If you totally fail, you can always go back to the previous stage. Therefore, it is good to always do small steps, because then, it is easy to fix.

Something else that we have applied now is the unit tests and the contignious integration. Hopefully, that will help us to keep tracking our code and see if everything is in good state and won’t affect the other functions in the program.

Chapter 1: Important to do things in small steps and test everything before you push.

Chapter 2: Super important to have version controll.

Chapter 3: Use contignious integration to easier check that the program is running correctly.

Chapter 4: Always use test on everything. Gives you a good feedback of the implementation.

Chapter 14: When you’re working on different branches, remember to check in and merge with main frequently.

[JoelScarinius]

Preperation for seminary 1

Throughout these chapters in the book a lot of focus is around how to implement Continuous Delivery in a big organization while working on development of software. The authors also pay attention to explaining the benefits with Continuous Delivery compared to other traditional software development delivery methods. We have tried our very best to apply the techniques explained in these chapters to our project and have started experience what great potential these techniques have when used in a favourable manner. We have also faced a lot of issues trying to set up the project the way the book suggests. This has been a great way for us to learn new things and work on our ability to troubleshoot and preform problem solving.

During these first weeks I have realised that when everything needed for Continuous Delivery is all set it is handy to always know that if the automated tests, the build and the run passes when pushing to the server, you know that your code will be runnable for the next person working on the project, this also means that you project always are ready to be launched in its current state. We are also able to find bugs in an early state when it is easier to fix, and this can also be done in an incremental way.

We have tried using version control through “git” which has helped us keep all work in one place accessible for everyone in our group. This has also made it possible for us to work separately on different branches that we have been trying to keep updated with the main branch as often as possible. The book talks about importance of version control and that you always should be able to regress to an earlier working state of your project. We have on some occasions been needing to practice this with successful outcomes.

The book focuses on how critical feedback in Continuous Delivery is and what benefits can be acquired through taking advantage of the feedback given. The authors also described this as a requirement to achieve your goals connected to the ongoing project. This is something that I totally agree with, because during our project I have noticed that we perform better as a group if we meet and discuss things regularly and help each other out. The authors also mention the different types of feedback that is necessary to take into an account to ensure a high-quality standard. For example, we have seen feedback from our automated tests as an important moment to learn more about what’s causing the problems. The book also includes information on how to measure and monitor the progression of the project and how to use that information in a way that will improve your working process going forward. I think this is something we could have gained a lot of insight from but maybe the lack of time for this project is a bit of an obstacle for us to take time to do this in a useful way.

One thing I found especially interesting in chapter 3 was that the authors stated that without Continuous Integration, the application can be considered broken until that you can show it is not. This is something we have been practicing with Rudy when showing him that our code works on lab sessions and from now on the Continuous Integration will show this for us.

We haven’t really considered implementing any security to our project this is something that the book mentions from time to time and is probably something we should investigate. I don’t think our project is in need of any advanced security but it is of course a good practice to start implementing security to your project, so you are ready to do this when working in a bigger organization in the future.

My main take-away from Chapter 1 is that the concept of Continuous Delivery favour organizations to deliver reliable software in a rapid fashion.

My main take-away from Chapter 2 is that Continuous Integration is a crucial piece of Continuous Delivery that helps organisations to test and build projects in a consistent manner.

My main take-away from Chapter 3 is that the authors highlight that if an organization only were to choose to implement one of the practices explained in the book, they encourage the organization to choose Continuous Integration.

My main take-away from Chapter 4 is the importance of always running the different types of tests after making any changes to the project to be able to fix bugs before pushing to the repository.

My main take-away from Chapter 14 is all the benefits of using different branches for implementing or improving features to your project.

[McFluffen]

Chapter 1 Foundations By working in a team, we are bound to do things differently and by creating a development foundation on how our project will be developed. The deployment pipeline applies to our project since this methodology is based on that every change or addon to the project should be compatible with the project (Linters, versions, etc.…) and work with the already existing features. By using this in our project we can stabilize the development because of the feedback which is given by using the pipeline methodology either by co-developers or tests. This makes it easy to quickly deal with problems that will arise in the development of the project. The pipeline approach to software development reduces errors, improves code quality, and enhances the development progress.

Chapter 2 Configuration Management When collaborating in a project with others there will be differences in how you handle the project’s files, how often you update your software, or which code editor you are using. By using Version control like Github or Gitlab we can easily track what version we are on and what features were added in each update. By using good commit messages together with version control and updates we can keep track of the project and manage eventual problems that arise in the versions. Another variant of version control we implemented since our project is based in Unity which receives updates frequently this problem has been discovered multiple times where version differences have created problems with compatibility between co-developers. By setting the version of Unity we should use the number of compatibility issues has decreased due to Version Control, the version is only changed when all the developers choose that. Version control is a crucial part of software development and software management.

Chapter 3 Continuous Integration When our game is runnable in a base state continuous integration will be a great way to keep track that the game is still playable and that additions to the game will not disturb or create bugs in features that were working before. The problem we will face when trying to implement CI is that tests are hard to run for games since most of the game’s inputs are user made. This will be a problem to handle by either finding a way to create good tests that “play” the game to check the validity of features. This will create a control layer for commits that will check if the current commit is runnable and create quick feedback to the developer to fix the issues. Good continuous integration will enlighten issues before being integrated into the application.

Chapter 4 Testing Strategy By having a high code coverage of our tests we will try to cover as much as the automated testing in the project. But since this is a game, a strategy of manual testing will be required to return feedback on problems or bugs in the game. This will slow the development process until a new way of testing is found. Testing should be an integrated practice in development.

Chapter 14 Advanced version control Our project will use branching to implement new features and issue fixes for bugs. This will create a project development where the main branch is built on features from the branch by merging them into the main branch. This will create an easy visual depiction of the stage of the project. Effective control systems are crucial for branching.

[MarrisSparrisNilsson]

The book explains in fine detail about what problems and difficulties software developers might encounter when working in teams to produce and deliver software and which actions they might take to make the development process as smooth as possible. By this I mean constructing a good configuration management strategy that lets you and your team maintain the application in a working state at all times, keeping track of - and documenting the project’s development process and allowing the software to be tested so that errors can be noticed in time before the errors gets too difficult to fix. All this and much more is taken into consideration and should at the same time not interfere with the goal of efficiently delivering software.

When taking a look at our development process so far I can really start to see how these principles can be of great benefit for both us as a small team and for larger teams in terms of time efficiency, preventing bugs to appear (that might have been caused by human error) thanks to automated processes and overall making delivering software so much faster and reliable.

When developing a software application either in a small or large group of developers, it is crucial to have good communication with the people you’re working with and give regular feedback to each other in order to ensure that the software will be delivered with the best quality possible. The authors stated the following: “Allowing feedback to happen only within silos and not across them is a recipe for disaster. It leads to local optimization at the expense of general optimization—and, ultimately, finger-pointing.”

When teams are working together and people make their own changes to the project the implementations they make might break some other part of the application that they didn’t expect, might end up with the latest version to be in a broken state that sometimes could become hard to fix. This is why the authors really try to emphasize the importance of following the principle of Continuous Integration. It allows us to always have a working version of the application and prevents broken code from being added without being noticed. To achieve this there are a few things that are required for it to work. The main things are the use of a version control system, build- and test scripts. When someone makes a change, their changes will have to go through certain build and test checks to ensure that the application is in a working state even with the newest changes. This will increase the rate at which new features can be added as it drastically reduces the time spent on back tracking to locate your issues and fixing them.

Working on different branches allows for implementing different features at the same time without affecting the other’s changes.

Take-aways: Chapter 1: Development processes should always be automated as much as possible. Humans can make a number of errors even with the right instructions but a computer will never fail its tasks as long as you provide it with the right instructions and tools. Giving humans more freedom and can instead focus on producing software.

Chapter 2: The better configuration management strategy the more control of the development process you will have.

Chapter 3: Continuous Integration will always provide us with a working state of the application.

Chapter 4: Make tests simultaneously as you start developing new features to be assured that the implementation is working.

Chapter 14: Make frequent checkouts of yours and others changes to make it available to your co-workers and to stay updated with the latest changes.