Today I'm happy to announce the first release of dev-suite, a cross platform collection of tools designed to redistribute distributed work and help remove vendor lock in from large corporations. You can find a read-only copy of the code on these three sites:

In an effort to build the future I laid out in my initial post about dev-suite I self host the write version of the repo and automatically push changes to the sites above so people can view the code on their platform of choice. The goal of dev-suite is to provide similar or better functionality to the above sites and have things live alongside your code so that it won't matter where you host your code. Making it easier to leave the platforms if they support organizations like ICE or do something you're not comfortable with. You're free to move wherever rather than being tied to a centralized service owned by some large corporation due to it's integrations and value add such as ticketing or CI/CD. I'll talk more about how this works with the tools released today and how you can get involved down below.

You can find this release's changelog on either:

Installation

The easiest thing you can do is grab the ds binary for your platform from one of the links below, putting it on your $PATH and marking it executable on Linux or OSX. Then just run ds install to install ticket and hooked. After that run ds config user init "Your Display Name"to initialize your computer with a config for you. If you don't other commands will likely fail to work

If you prefer to compile things yourself or run into issues check out the instructions about how to install the tools manually.

Dependencies
Make sure you have git installed and for Windows, make sure Git for Windows is installed to the default location on the C drive for hooked to work properly as we have to depend on a full path to sh.exe which comes with it.

Initializing your Repo

Once you've got everything installed, in a newly initialized git repo or current repo run ds init and you'll be prompted about which tools in dev-suite that you wish to use for your project. Select the tools you want and follow any secondary prompt. That's it! Everything should be setup for you to use ticket and/or hooked. If you want to add a tool in later that wasn't in your choices with ds init then don't worry. Each tool also has it's own init command you can run to add it into the repo.

Setting up a new repo with ds init

Hooked

hooked is a tool to create and link git hooks. No more getting the arguments to ln backwards, having issues about getting hooks to work for different platforms, and have them travel with your repo. You can choose to initialize your repo to use either Bash, Ruby, or Python for now. Windows was a bit tricky to get it working for, but this release does have it in workable state out of the box. Make sure on Windows you have a working copy of py.exe (which should come with a Python 3 installation) or ruby.exe on your PATH depending on the language you choose. We have access to bash.exe as long as you install Git for Windows to the default location as mentioned above.

If you're already using a hooked enabled repository and want to set them up for a new machine or clone of the repo just run hooked link and they'll automatically be symlinked to your .git/hooks folder.

dev-suite currently uses hooked as a way to do CI by making sure the code works at each commit using a pre-commit hook. If you want to skip these you can always pass in --no-verify, but I've not needed to do so really. It's been immensely helpful and allows me to push to master directly. Ideally I'd like to enable developers to do more trunk based development and to allow projects to use git hooks to easily enforce things client side before they get pushed that would take up precious CI build time among other things. I've had a great experience using git hooks and I hope you'll give them a shot with hooked in your repo.

Ticket

ticket is a tool to create tickets and have them live alongside your code. Not only will it live as part of your history, but you can also close the ticket as part of the commit that fixes it. I've found this to be a great experience so far and I hope you will find it to be so too.

ticket is not only a CLI tool you can use to manipulate the tickets like assigning users, opening new ones, closing old ones, and printing out tickets. It's also got a TUI you can use to view them right in your terminal and add comments easily from there. Since it's built with the crossterm backend for the tui-rs crate it works on all three major platforms! In order to use it just type and run ticket in a repo with tickets enabled.

The tui for ticket in action

Check out the README for all the possible commands that you can run from the commandline or just run ticket -h to get help.

Internally ticket uses UUID v1 so that everything is unique and sortable by time no matter when or where someone adds a ticket or comment. Having to use the full ID feels a bit verbose currently and is something I'll want to work on in the future, but it works well for now! All of the tickets are stored on disk so if the cli tool is not doing what you need you can always manipulate it there, but also please send in a feature request if it's missing functionality or file a bug if it's not working the way you expect.

ticket has been a joy to work on and one of the easiest ways to see how we can unlock code from being stuck on centralized vendors. I hope you have fun using it!

Contributing

Part of dogfooding dev-suite's tools means figuring out how to make contributing easy. It's not expected to be easy for a while, but that's part of the fun; solving really hard problems. However, it's not impossible and working towards this is the end goal of this project. There are a few ways you can contribute. Many of them involve interacting with the mailing list:

Commit Messages
Before jumping into all of the below ways you can contribute please note that any commits being submitted must be in the form laid out in this blog post. In summary all commits must have the following form:

  1. Separate subject from body with a blank line
  2. Limit the subject line to 50 characters
  3. Capitalize the subject line
  4. Do not end the subject line with a period
  5. Use the imperative mood in the subject line
  6. Wrap the body at 72 characters
  7. Use the body to explain what and why vs. how

Commits not following this will be rejected though number seven as a requirement is a bit more lax.

Feature Requests
There's a lot of things dev-suite can be and while there already some ideas for future work it's nice to hear what people want out of their tools. Feature requests will not be considered issues until they've been actively accepted as something to be worked on. With that in mind please feel free to send in your requests to the wish list topic in the mailing list.

Filing Issues
Bugs are inevitable feature of all software. If you find a bug please file an issue with ticket in your own fork and send an email to the issues topic in the mailing list with where it can be pulled from and it will get integrated it into the repo. Comments added to issues should be done the same way as well. If it's a feature request follow the above to send that in. In the future finding a way to automate this part so that you can just send an email and have it merge the issue or comment automatically would be great.

Adding code or sending in bug fixes
Much like filing issues send an email to the mailing list with [PR] and what the PR is for in the subject and a link to a publicly accessible repo where the commits can be pulled from for review. Discussion will happen on that thread until changes are accepted. Please follow the Commit Messages guidelines when doing this. The history is not going to be cluttered with those that don't follow the rules above. Having a nice git log to work with is absolutely critical. Please also do not send patches by email. Sending patches screws up the history and email clients do all kinds of stuff with newlines and white space. git was designed to work in a distributed manner. Just make the repo public and your changes should be able to be pulled in to the main repo!

Conclusion

I hope you have fun kicking the tires and giving dev-suite a try so that you can see the glimpse of a future where you have more choice of where your code lives and having it carry the context of project management with it. I'm excited to continue adding new features and working on new tooling to make things like PRs part of your git history and easy to do for things like OSS where having write access is not shared among everyone. If you want to discuss dev-suite or do any of the above please send an email to the mailing list. If you only just want to send along a little bit of praise or talk about dev-suite outside of things worthy for public discussion you can email me personally at self@mgattozzi.dev or contact me on Twitter.